PATENTSCOPE sera indisponible durant quelques heures pour des raisons de maintenance le lundi 03.02.2020 à 10:00 AM CET
Recherche dans les collections de brevets nationales et internationales
Une partie du contenu de cette demande n'est pas disponible pour le moment.
Si cette situation persiste, contactez-nous auObservations et contact
1. (WO2015172205) AUTHENTIFICATION, AUTORISATION ET COMPTABILITÉ D’ENTITÉ INTERACTIVE
Document

Description

Title of Invention

Technical Field

0001  

Background Art

0002   0003   0004   0005   0006   0007  

Summary of Invention

0008   0009   0010   0011   0012   0013   0014   0015   0016   0017   0018   0019  

Technical Problem

0020   0021   0022   0023  

Solution to Problem

0024   0025   0026   0027  

Advantageous Effects of Invention

0028  

Brief Description of Drawings

0029   0030   0031  

Example 1

0032   0033   0034   0035   0036   0037   0038   0039   0040   0041   0042   0043   0044   0045   0046   0047   0048   0049   0050   0051   0052   0053   0054   0055   0056   0057   0058   0059   0060  

Industrial Applicability

0061   0062   0063   0064   0065   0066   0067  

Claims

1   2   3   4   5   6   7   8  

Drawings

1   2   3  

Description

Title of Invention : INTERACTIVE ENTITY AUTHENTICATION, AUTHORISATION AND ACCOUNTING

Technical Field

[0001]
This invention is in the field of protecting assets (e.g. humans, devices, services, products, systems and properties) against unauthorised activity.

Background Art

[0002]
Most authentication, authorisation and accounting (AAA) systems are only effective in preventing new attacks. For example, introducing stronger encryption of passwords. This invention can be deployed to protect an asset even after the asset has been compromised (e.g. passwords of all users have been leaked).
[0003]
Most AAA systems detect unauthorised activities based on the checking the user supplied value with the expected value of certain attributes e.g. static passwords, X509 certificates, fingerprints, phone numbers, IP addresses etc. This invention can check without needing an exact copy of supplied value.
[0004]
Most AAA systems rely on the supply of identity information by the individual user first e.g. username, password etc. before checking can be initiated. This invention can initiate checks before the user has supplied individual identity information.
[0005]
Most AAA systems introduce an extra layer of operation for the user e.g. security tokens, SMS verification etc.; it is an extra burden every time the user wants to access the asset. This invention works transparently in the background and only interacts with the user when extraordinary events occur.
[0006]
Most AAA systems are difficult to set up and maintain for the asset operator e.g. resetting passwords, issuing security tokens, configuring public key infrastructures etc. This invention is highly automated making it easy and low cost for the operator.
[0007]
Most AAA systems need to use and store low level user access details for analysis. This invention can store only high level derived information, enhancing user security and privacy.

Summary of Invention

[0008]
This invention, Interactive Entity Authentication, Authorisation and Accounting (IEAAA), is a set of systems and methods that provide an extra layer of authorisation to enhance protection of assets, based on higher level entity values instead of low level attribute values (used by traditional authentication layers).
[0009]
During the user authentication and authorisation processes, a number of identity attributes are available, some are supplied directly by the user (e.g. user password), while others can be obtained from the environment (e.g. IP address of user). Unlike traditional security systems, which use these user attributes and environment attributes directly, this invention acquires the entities that these attributes belong to and uses the higher level entities in the authentication and authorisation processes.
[0010]
Some examples of entities that this invention uses instead of their corresponding identity attributes are: (1) IP Entity - the owner of the IP address instead of the IP address itself; (2) Password Entity - the algorithm that is used to generate the password instead of the password itself; (3) URL Entity - the domain that the uniform resource locator (URL) belongs to instead of the whole URL.
[0011]
The invention includes 4 modules: Entity Acquisition Module (EAM), User Interface Module (UIM), Asset Interface Module (AIM) and Continuous Improvement Module (CIM). [Fig. 1]
[0012]
The EAM takes the incoming identity attributes (e.g. IP address 139.130.4.4) and acquires the corresponding entity for them (e.g. IP Entity “telstra.com”). It then checks the incoming entity (e.g. “telstra.com”) against a list of stored entities for that user (e.g. “telstra.com”, “vodaphone.com”, “verizon.com” etc.). This user-entity list can be maintained by any of the 4 modules. Each user and entity on that list has at least these parameters: (1) an expiry time parameter, after which the user cannot use the expired entity anymore. Different expiration periods allow temporarily entities (e.g. IP Entities from public hotspot or global roaming IP address) to be expired quickly. (2) a rate limit parameter, if there are too many checks or maintenance actions per time period then a response will be made e.g. sending an alert to the UIM and AIM.
[0013]
The UIM is responsible for interacting with the user via the user’s preferred communication method e.g. SMS, instant message, emails, web browser, voice calls etc. UIM supports at least 3 basic functions: (1) AAA – authentication, authorisation, accounting e.g. checking entities supplied during authentication are on the list of allowed entities for the user; (2) update – adding and removing entities into the entity list of a user; (3) notification – informing the user of relevant events.
[0014]
The AIM is responsible for interacting with the asset via the asset’s preferred communication method e.g. REST, SOAP APIs etc. AIM supports at least 3 basic functions: (1) AAA – authentication, authorisation, accounting e.g. checking entities being accessed by the user are in the user’s allowed listed of asset entities; (2) update – adding and removing entities into the entity list of a user; (3) notification – informing the asset of relevant events.
[0015]
The CIM is responsible for encrypting, storing and constantly analysing events across all users, entities and assets, so accounting can be perform and continuous improvement can be made to the operation of the invention in real time.
[0016]
This invention supports at least 3 operation modes: (1) Redirect Mode, (2) Proxy Mode and (3) Backend Mode. [Fig. 2]
[0017]
In redirect mode, users are connected with the UIM, which will consult with the EAM in order to perform user AAA. If successful, users will be redirected to the Asset, at the same time the AIM will notified the asset of the redirection. If unsuccessful, UIM will initiate an Interactive User Verification (IUV) with those users. IVP will interact with the user to ensure that the new entity used by the user is legitimate and then adds that new entity into the user’s entity list. With redirect mode, the AAA is performed by the UIM on demand e.g. AAA may be only be needed once at the beginning of a user session.
[0018]
The proxy mode is always on. Instead of getting out of the communication path after a successful AAA, the user remains connected to the UIM and is passed through to the Asset via the AIM. Since the User accesses the asset through the UIM and AIM, the UIM can continuously monitored all user and environmental attributes. With the UIM staying in the communication loop, AAA are constantly being performed in the background on the usage patterns of the User.
[0019]
In backend mode, users authenticate and gain authorisation directly with the asset, the asset will gather and send identity attributes to the AIM, which will consult with the EAM, and results are then sent by the AIM back to the Asset. It is up to the asset to decide what to do with the result e.g. the asset can tell the UIM (via the AIM) to perform an IUV with the users if needed.

Technical Problem

[0020]
The following are some technical problems with traditional AAA systems using identity attributes directly.
[0021]
IP Address Problem: Detection of changes in the IP address attribute of a user is a popular way of picking up potential security violation; unfortunately IP addresses change too often due to mobile or fixed devices having dynamic IP address assignments. Some operators attempt to reduce the impact of those frequent changes by tracking the location of the IP address instead of the IP address itself. Problems with the location approach are the inaccuracy of the mapping from an IP address to a location and the fact that users can be very mobile thus changing locations quickly.
[0022]
Password Problem: Using the static password as an identity attribute has a lot of problems. Using short password is dangerous, yet remembering long passwords is very difficult. Even without sophisticated keyboard logging or screen recording malware, user passwords are easily exposed during normal communications in emails, instant messages, SMS or as DTMF tones on the phone network.
[0023]
URL Problem: The URL is a fundamental way of accessing resources within an asset. URL history of a user provides very good clues as to whether the accesses are legitimate. Unfortunately, in its raw form, the URL is extremely difficult to use. There are numerous URLs involved in each session and they vary widely depending on the resource and asset being accessed. It can contain random components e.g. session IDs and the characters can be encoded e.g. in hex instead of ascii.

Solution to Problem

[0024]
The following are some solutions to the above technical problems by using entities instead of identity attributes in AAA.
[0025]
IP Address Solution: Instead of using an IP address like “139.130.4.4”, its IP Entity “telstra.net” is used. No matter how many times the IP address changes the IP Entity remains the same for the user. A hacker from overseas or even locally on a different network will have a different IP Entity and can be exposed.
[0026]
Password Solution: Instead of having a short static password, like “76568”, a long dynamic password, like “3221163565569437”, can be generated from the Password Entity. A sample algorithm that can be based on the date time yy-mm-dd hh:mm:ss, the user only has to remember “2 random digits in front of date seconds” in order to generate the above dynamic password e.g. the current date time is 15-05-21 13:23:16, so the user put in 2 random digits “32” and then append the date and seconds from the watch “2116” to it, after that it is just adding as many random digits as the user wants “3565569437” behind. It is up to the user to pick how many of those 12 digits from the date time yy-mm-dd hh:mm:ss will be use in the dynamic password and also where they will be placed amongst the random digits. Dynamic passwords generated by an algorithm are of much less use to a hacker than static passwords.
[0027]
URL Solution: Instead of dealing with URLs like “http://www.example.com/rewrw/rwer/rwr/rre.htm?w=sdfsf&y=ggdg&z=gghdk” the URL Entity can be something simple like “example.com”.

Advantageous Effects of Invention

[0028]
Unlike identity attributes, entities are derived, so rarely need to be transmitted and thus exposed over the network. Working at the higher granularity level of the entity instead of the individual identity attributes results in benefits like faster operation, greater tolerance of change, resistance to minor variations, reduction in storage, improvement in privacy.

Brief Description of Drawings

[0029]
Figure 1 [Fig. 1] is a block diagram of the invention, showing internal communication paths between the 4 modules (UIM, AIM, EAM, CIM) and external communication paths to the user and the asset.
[0030]
Figure 2 [Fig. 2] illustrates some operations modes of the invention, including redirect, proxy and backend.
[0031]
Figure 3 [Fig. 3] shows the naming of different components of an URL.
[0032]
Since the invention’s 4 modules are all fully interconnected and fully programmable, there are many possible embodiments. The following are examples of some embodiments for handling identity attributes IP address, Password and URL.

Example 1

[0033]
IP Address to IP Entity
[0034]
One way which the IP Entity can be acquired from an IP address is by going through the following steps:
[0035]
Step 1 is to get the Reverse DNS entry of the IP address, remove the host component in front and use the domain component as the IP Entity e.g. 139.130.4.4 will have a reverse DNS of 4.4.130.139.in-addr.arpa domain name pointer uneeda.telstra.net. from there we can remove the host component “uneeda” from “uneeda.telstra.net” to get an IP Entity of “telstra.com”.
[0036]
Step 2 can be used if there is no Reverse DNS for an IP address. The email domains inside the IP address whois record can be used as the IP Entity e.g. the whois record of 139.130.4.4 has the following email address inside IRT@team.telstra.com and the domain “team.telstra.com” can be used as the IP Entity. There are normally more than 1 email address inside the whois record, so all the NIC based email addresses have to be removed first e.g. “nobody@apnic.net” will not be used. Of the remaining email addresses, the most frequent appearing email address can be used for extract of the domain. If multiple email addresses have the same appearance frequency, then pick the email address with longest domain name e.g. IP Entity is “team.telstra.com” instead of “telstra.net” since it is longer.
[0037]
Step 3 can be used if there is no relevant email addresses in the whois record of the IP address. For IPv4 IP addresses, the Class C of the IP address is extracted e.g. from 8.8.8.8 we get 8.8.8.0, then the whois record is scanned to identify a line containing the Class C, the first word of the line is made into lowercase and used as the IP Entity e.g. for the line “Google Inc. LVLT-GOGL-8-8-8 (NET-8-8-8-0-1) 8.8.8.0 - 8.8.8.255” in the whois record of 8.8.8.8 the IP Entity is “google”.
[0038]
Step 4 can be used if other steps failed to create a meaningful IP Entity. In this step, whois records from multiple IP addresses within the same Class C are compared, and the differences (e.g. dynamic information like the IP addresses) are stripped out of to create a common whois record. A hash (e.g. md5) of this common record is then used as the IP Entity e.g. “48d79f7eba59f18586c6d818aed8675f”
[0039]
Step 5 can be used if other steps failed to create a meaningful IP Entity. In this step, instead of using the IP address itself, the IP address of its upstream router is used instead. The IP address of the upstream router can be discovered using programs like traceroute. Steps 1 to 4 can be applied to this upstream router IP address to see whether meaningful IP Entity can be obtained. This step can keep repeating itself, moving to the IP address of the upstream router of the upstream router etc. Note that after a few iterations the IP address of upstream router will no longer be relevant since it has moved too far away from the original IP address already.

Example 2

[0040]
Bootstrapping
[0041]
To boot strap the operation, the asset can supply past history records of the users by loading them into the EAM through the AIM. The EAM can then scan those records and acquire the entities from relevant attributes for each user. For example, a user has been accessing the asset from 12 different IP addresses over the past 3 months; the EAM has extracted 3 IP Entities from those IP addresses; every time that user accesses the asset from now on, the EAM will already know about the IP Entities to expect.
[0042]
Bootstrapping is a good way building up a store of entities, but it is not absolutely required, new entities can be added in real time via other processes.

Example 3

[0043]
Interactive User Verification (IUV)
[0044]
If a user comes in on a new IP Entity, for example “telstra.net” then the IUV process will be initiated. IUV is a fundamental part of the invention, since without a rapid way of updating the entities a coarse grain approach will create too much inconvenience. IUV can be performed using many different methods. The following are some possibilities.
[0045]
When the invention is used to protect a VoIP service, the IP Entity of all voice calls are checked against the callers’ past IP Entities. If there is no match, the call will not be put through to the destination as dialed, instead a voice prompt will be played to the caller “This is the first time you called from internet provider telstra.net. For security purpose we will ring your predefined phone number with last 3 digits XXX shortly for verification. Goodbye.” A call is then placed to a predefined phone number, by default it is the supplied phone number of the user during initial account registration. UIM calls out to the account holder and plays: “This is a call from your Internet Phone Service. The system has detected attempts to make Internet Voice calls via your account using a new Internet Provider. The Internet Provider is telstra.net. Are you trying to make Internet Voice Calls using a new Internet Provider? To confirm that you are making calls using a new Internet Provider, Press 1. If you are NOT using a new Internet Provider, Press 2”. If the Account Holder pressed 1, system plays: “Your new Internet Provider has been added. You can make call from it now. Goodbye.” If the Account Holder pressed 2, system plays: “Someone is attempting to make calls using your account and their Internet Provider telstra.net has now been blocked. Contact support for details. Goodbye.” Further calls with that user account from the now blocked telstra.net will now get the voice message “We are sorry but your Internet Provider has been blocked from calling out using your account. If you wish to unblock it, please contact our support team. Goodbye.”
[0046]
When the invention is used to protect a web site, the IP Entity of all connections is checked even before the identification of the user. If the IP Entity has a bad reputation, the connection will either be dropped or flagged for extra verification. Once the user has entered identification information, the IP Entities associated with that user will be checked. If the IP Entity is new then a message like “This is the first time attempted login from this internet provider telsta.net. For security purpose we have sent a 4 digit random number to your predefined phone number with last 3 digits XXX verification. Please enter the random number below to add telstra.net into your profile and continue logging into the system.”

Example 3

[0047]
Password Entity to Password
[0048]
Static passphrases (a long password with a few words inside) are still needed for authentication, especially over secured communication channels. The Password Entity is an “alternative” when the communication channel is not secure e.g. DTMF tone over the phone network and when the asset is not of high value e.g. casual social site. Password Entity can also be used as an “additional” authentication method in high security situations.
[0049]
The 12 date time digits yy-mm-dd hh:mm:ss can be used as a base for generating a dynamic password, the user has to predefine how many of those 12 digits will be used and where they will be placed amongst random numbers. An example, of such an application is list under the section “Solution to Problem” above.
[0050]
Further transformation to the time digits before inserting into the random digits are possible, e.g. by adding 2 to the seconds, as long as both sides (the user and UIM) agrees on a common protocol. But that is rarely necessary.
[0051]
Although both the user and the UIM will have pretty accurate clocks, a difference in time is still possible. Thus the UIM will allow a grace period configurable by the user, so the time digits between the user and the UIM can be off by plus or minus a number of seconds and the Password Entity will still authenticate correctly.
[0052]
The UIM also allows the user to change the algorithm used in the Password Entity at any time by supported out-of-band communication methods e.g. via SMS. This makes the Password Entity even more secure.

Example 4

[0053]
URL to URL Entity
[0054]
URL Entity is just an condensed version of the URL, there are many ways of converting an URL to URL Entity, the following is just one way of doing so. [Fig. 3]
[0055]
(1) Remove the Scheme, Fragment, Login, Port parts of the URL (2) Keep only the first character of each component in the Directory removing all slashes in the middle (3) Keep only the extension of the File (4) Sort the KeyVaue in order, keep only the first character of each KeyValue (5) Remove all other characters and make all lowercase.
[0056]
For example “foo://user:password@example.com:8042/over/there/abc.png?name=ferret&type=good#nose” becomes “example.com/ot/png?nt”
[0057]
Due to the compression achieved an URL Entity can map to multiple URLs, this allows authorisation to be performed much easier, as the permissions are now given based on URL Entities instead if URLs. Each user can now be mapped to a smaller number of permissions but still have access the same number of resources on the different assets as before.

Example 5

[0058]
Accounting
[0059]
At the entity level accounting can be perform more efficiently. Accounting records are stored and can be analysed and actioned by each EAM, UIM, AIM independently. The CIM has an overall global view for deep insight purposes or for audit purposes.
[0060]
If the AIM discovers that a user has been attempting to access an unauthorised URL Entity, it will send an alert to the asset operator, but it can also send a message to the user via the UIM, if needed.

Industrial Applicability

[0061]
Anything that has an IP address (web browsers, private tunnels, mobile apps, software APIs) can use IP Entity for extra protection.
[0062]
When the whole password database of millions of users has been leaked, the invention can be deployed to quickly restrict the hacker’s ability to exploit that database. As it is extremely difficult to find out and then get onto the same IP Entities as so many users.
[0063]
A lot of Voice over IP (VoIP) devices is easily hacked with their account passwords stolen; this costs users a lot of many as expensive calls are made through them. This invention can allow calls from only know IP Entities.
[0064]
Email spoofing is a common fraud that claims a lot of victims. This invention can check the IP Entity of the sending email server to make sure that it matches that of past IP Entities from that sending email address (that email address is now a “user”). If there is no match insert warning message can be inserted into the email.
[0065]
All authentication applications, whether online or offline, can benefit from this invention since it works at the higher entity level, complementing the low level attribute based methods used by existing systems. From industrial sensors to web banking, tracking the changes in IP address owner is always more efficient that tracking the IP address themselves.
[0066]
A child protection system can be built with this invention that supports comprehensive classification of URLs base on URL Entities.
[0067]
This invention can operate independent of the asset. This is great for privacy since the end user can now operate this invention themselves to obtain AAA functionality across multiple asset operators.

Claims

[Claim 1]
An authentication, authorisation, accounting (AAA) system comprising at least an Entity Acquisition Module (EAM), a User Interface Module (UIM), an Asset Interface Module (AIM) and a Continuous Improvement Module (CIM). The users are connected to and interact with the UIM, while the assets that the users want to access are connected to and interact with the AIM.
[Claim 2]
A method for authentication, authorisation, accounting (AAA), the method comprising at least an Entity Acquisition Module (EAM), a User Interface Module (UIM), an Asset Interface Module (AIM) and a Continuous Improvement Module (CIM). The users are connected to and interact with the UIM, while the assets that the users want to access are connected to and interact with the AIM.
[Claim 3]
The system of claim 1, using information derived from IP addresses.
[Claim 4]
The system of claim 1, using algorithms for the generation of dynamic passwords.
[Claim 5]
The system of claim 1, using algorithms for compression of URLs.
[Claim 6]
The method of claim 2, using information derived from IP addresses.
[Claim 7]
The method of claim 2, using algorithms for the generation of dynamic passwords.
[Claim 8]
The method of claim 2, using algorithms for compression of URLs.

Drawings

[ Fig. 1]
[ Fig. 2]
[ Fig. 3]