Patent Application
20090199009
The present invention relates generally to methods, systems and computer program products for authorizing ad-hoc access and more particularly to systems, methods and computer program products for granting ad-hoc access to network services and/or network devices.
Network access typically requires users to go through a registration process before network services are provided to those users. Registration is usually carried out by a service administrator who has the right to grant or deny access rights to various potential users. This approach has the disadvantage of having to rely on a service administrator to carry out the registration process.
Authorization to access network-based services can be granted on an ad-hoc basis without requiring a user to go through a tedious registration process. However, a user who accesses a network on an ad-hoc basis is one who needs to access the resources in a network on a temporary basis and may or may not access the same network again at a later time. Generally, ad-hoc users of a network do not have a security association with the network and therefore cannot communicate securely with devices in that network.
One method for granting ad-hoc access to a network device or service is to create a generic account specifically for ad-hoc users, e.g., a guest account. However, use of a common guest account disadvantageously prevents differentiation of access rights between ad-hoc users. In order to enable differentiation of access rights, tokens, certificates or authorization tickets may be used as a means for authorizing a user to access services in a network. Access tokens may be used to allow devices to gain temporary access to a network with restricted privileges.
One system that uses tokens for access control purposes is disclosed in U.S. patent application No. 20030196087, which provides secure access to documents or services residing on a personal network by granting access tokens for temporary access.
Other methods for transferring trust are based on the use of an external, trusted third party. The third party acts as a guarantor for the identity of a party. One such system is the Kerberos protocol, which is a network authentication protocol that enables parties communicating over an unsecured network to prove their identity to one another in a secure manner using secret-key cryptography. For example, Kerberos enables a client to prove its identity to a server and vice-versa across an unsecured network connection and helps to ensure the integrity of the data transferred by preventing or reducing the possibility of eavesdropping or replay attacks.
Another existing system is Smart Right (URL: <www.smartright.org>), which is primarily directed to content protection using smart cards as terminal cards to store user identity. The Smart Right Certification Authority is used to certify the public keys stored in the Smart Right terminal cards.
Other third party trust systems and methods include certificate authorities such as Verisign, Thawte Consulting and Societá per i Servizi Bancari (SSB S.p.A.). A disadvantage of these methods and systems is that an external, trusted third party is required.
Accordingly, a need exists to provide methods, systems and computer program products for authorizing or granting access that do not rely on an external, trusted third party.
A need also exists to provide methods, systems and computer program products for distributing an access token solely to a requesting device or user in an unsecured environment.
Aspects of the present invention relate to methods, systems and computer program products for authorizing ad-hoc access.
According to an aspect of the present invention, there is provided a method for granting a requesting device ad-hoc access to a network. The method comprises the steps of sending an access pre-token via an unsecured communication channel to the requesting device, sending an access token associated with the access pre-token via a secure communications channel to a proxy device having a security association with the requesting device and granting ad-hoc network access to the requesting device subject to the requesting device providing information derived from the access token.
The information derived from the access token may comprise information specific to the access token and/or cryptographic key information retrieved from the access token. The method may comprise the further step of forming a security association with the requesting device using the cryptographic key information. The method may comprise the further step of receiving a request for ad-hoc network access from the requesting device via an unsecured communication channel, with the access pre-token and the access token sent in response to the request. The method may comprise the further steps of issuing a challenge to the requesting device and receiving a response to the challenge, the response comprising information derived from the access token. The challenge may comprise a random number and the step of granting ad-hoc network access to the requesting device may be further subject to the response comprising information relating to the random number.
Other aspects of the present invention provide systems and computer program products for implementing a method for granting a requesting device ad-hoc access to a network.
One particular aspect of the present invention provides a system for granting a requesting device ad-hoc access to a network. The system comprises an authorization authority for authorizing access to the network by the requesting device and an authorization controller for granting ad-hoc network access to the authorized requesting device. An access token is sent by the authorization controller via a secure channel to a distribution proxy having a secure association with the requesting device and the authorization is subject to the authorization authority receiving information derived from the access token from the requesting device.
The information derived from the access token may comprise information specific to the access token and/or cryptographic key information retrieved from the access token. The system may further comprise means for forming a security association with the requesting device using the cryptographic key information. The authorization authority may comprise reception means for receiving a request for ad-hoc network access from the requesting device via an unsecured communication channel and transmission means for sending an access pre-token and an access token in response to the request. The authorization authority may comprise transmission means for issuing a challenge to the requesting device and reception means for receiving a response to the challenge from the requesting device.
Other aspects of the present invention provide a method, a system and a computer program product for managing ad-hoc network access. The method comprises the steps of receiving a request for ad-hoc access from a device, which comprises a pre-token sent to the device via an unsecured communication channel; sending a token associated with the pre-token via a secure communications channel to a proxy for the device in response to the request; receiving a communication from the device; and determining whether to grant ad-hoc access to the device based on the content of the communication.
The system and computer program product may be used to practice the method for managing ad-hoc network access.
Yet another aspect of the present invention provides a token for granting a requesting device ad-hoc access to an unsecured network. The token comprises an access pre-token for the requesting device to identify itself to an authorization controller during an ad-hoc request and an access token for enabling the requesting device to validly respond to a challenge issued by the authorization controller to gain ad-hoc access to the unsecured network.
The access pre-token may comprise identification information for matching the access pre-token to the access token. The access pre-token may comprise a key for securing a communication channel during an ad-hoc access request. The access token may comprise information for identifying a network location of the requesting device issuing the ad-hoc access request, identification information for matching the access token to the access pre-token and a key for securing a communication channel between the authorization controller and the requesting device. The access token may comprise a validity tag for indicating validity or invalidity of the access token and/or a validity time for indicating a validity lifetime of the access token. The access pre-token may be used to secure a communications channel when the requesting device issues a request for ad-hoc access to the unsecured network.
A small number of embodiments are described hereinafter, by way of example only, with reference to the accompanying drawings in which:
Embodiments of methods, systems and computer program products are described hereinafter for authorizing and/or granting ad-hoc access to networks.
Certain of the embodiments are described with reference to Personal Area Networks (PANs), which generally comprise the interconnection of network devices within a certain range of an individual, typically 10 meters. Interconnection of devices in a PAN is based on a security association formed either directly or indirectly between the devices. Types of devices include, but are not limited to, laptop computers, notebook computers, personal digital assistants (PDAs) and mobile telephones, which may be interconnected and/or connected to other networks such as the Internet via wires and/or wirelessly. However, it is not intended that the present invention be limited to PANs as the principles of the present invention have general applicability to ad-hoc access of other networks, including known public and private networks.
Use of the term “authorization authority” in this document refers to a decision point, entity or device for authorizing access to a PAN or other network.
Use of the term “authorization controller” in this document refers to an entity or device that is the enforcement point for granting or denying access to a PAN or other network based on a decision of an “authorization authority”.
An authorization authority and an authorization controller may be consolidated in a single device.
Use of the term “distribution proxy” in this document refers to an entity within a PAN or other network of an access requesting device, which provides a secure channel to another PAN or other network which the requesting device is requesting access to.
Device 11 and gateway 12 form part of Personal Area Network (PAN) 19 and can communicate securely via internal channel 15. Similarly, device 13 and gateway 14 form part of PAN 110 and can communicate securely via internal channel 17.
Device 11 is configured as an authorization authority 11a for determining whether access to PAN 19 (or devices forming part of PAN 19) should be granted to devices or networks external to PAN 19. Gateway 12 functions as a proxy to PAN 19 for purposes of secure communication with networks or devices external to PAN 19. Gateway 12 is also configured as an authorization controller 12a for enforcing access decisions made by authorization authority 11a.
Gateway 14 functions as a distribution proxy 14a to devices forming part of PAN 110 when those devices communicate with devices external to PAN 110. For example, gateway 14 functions as a distribution proxy 14a for device 13 when device 13 requests ad-hoc access to PAN 19 via an unsecure communications channel 18.
The system shown in
Device 13 and authorization authority 11a do not have a pre-established security association. Thus, device 13 requires authorization from authorization authority 11a to access devices or services (e.g., multimedia services) hosted by devices that form part of PAN 19. However, authorization controller 12a and distribution proxy 14a have a pre-established security association. Thus, any device in PAN 110 having a security association with distribution proxy 14a is able to securely transfer information to PAN 19 via a secure channel 16 that can be formed between authorization controller 12a and distribution proxy 14a. Similarly, any device in PAN 19 having a security association with authorization controller 12a is able to securely transfer information to PAN 110 via secure channel 16.
Security associations may be established by known methods such as those described in an IETF IPSec Working Group document available at URL <http://www.ietf.org/html.charters/ipsec-charter.html>. Once a security association has been established between two devices, the devices can proceed to establish a secure communications channel using known methods at the IP Layer such as IP Tunneling or known methods at the Transport Layer such as Transport Layer Security, Secure Socket Layer (SSL) or a layer 2 tunneling mechanism such as Layer 2 Tunneling Protocol with extensions. Transport Layer Security is described in an IETF document available at URL <http://www.ietf.org/html.charters/tls-charter.html>. Secure Socket Layer (SSL) is described in a draft document available at URL <http://wp.netscape.com/eng/ssl3/draft302.txt>. Layer 2 Tunneling Protocol with Extensions is described in an IETF working group document available at URL <http://www.ietf.org/html.charters/I2tpextcharter.html>. Any of the foregoing methods, combinations of them or other known methods may be used to establish a secure communications channel.
Authorization authority 11a, authorization controller 12a, requesting device 13 and distribution proxy 14a may each be hosted by an independent mobile device (e.g., a PDA or notebook computer system) or an independent static or non-mobile device (e.g., a personal computer workstation). If authorization authority 11a and authorization controller 12a are remote from one another, authorization authority 11a should be capable of forming a remote secure channel with authorization controller 12a for secure communications. For example, a Virtual Private Network (VPN) may be setup between authorization authority 11a and authorization controller 12a. Similarly, a VPN may be setup between requesting device 13 and distribution proxy 14a. Further information regarding VPNs is available in a Virtual Private Networks Consortium document available at URL <http://www.vpnc.org/vpn-standards.html>.
Requesting device 13 and authorization authority 11a cannot communicate securely on account of not having a direct security association. Communications via an unsecured channel are vulnerable to impersonation and man-in-the-middle attacks. Although key exchange may be performed via an unsecured channel (e.g., using public-key encryption methods such as Diffie-Hellman) such communications are also vulnerable to man-in-the-middle attacks.
Embodiments of the present invention use associated pairs of an access token and a pre-token for authorization of ad-hoc network access. In the system of
An ad-hoc access request is issued (event 21) by requesting device 13 to authorization authority 11a. Authorization authority 11a processes the request (event 22) and determines whether to grant ad-hoc access to device 13. Processing (event 22) involves the authorization authority 11a matching the requesting device 13 to a list of PAN ID stored in the authorization authority 11a. PAN ID identifies the PAN the authorization controller 12a has a security association with.
Assuming that ad-hoc access is granted, a pre-token is issued (event 23) to requesting device 13 by the authorization authority 11a via an unsecured channel. However, the pre-token can alternatively be issued via a secured channel, for example, using a physical cable, “touch-based” technology, or other existing secure location limited access technology. An access token, associated with the pre-token, is issued (event 24) via a secure channel from authorization authority 11a to authorization controller 12a. The identity of the requesting device 13 and its corresponding PAN ID are sent with the access token to the authorization controller 12a. PAN ID is used by the authorization controller 12a to locate the distribution proxy 14a.
In the embodiment shown in
Requesting device 13 enters the domain of PAN 19 by forwarding an access request accompanied by a pre-token (event 31) to authorization controller 13. The pre-token was previously issued by authorization authority 11a (for example, according to the event 24 in
Authorization controller 13 processes the access request (event 32) and retrieves the access token associated with the pre-token. The corresponding access token is passed to Distribution Proxy 14a (event 33).
Authorization controller 12a issues a challenge (event 34) with an attached random number to requesting device 13 that requires a response from requesting device 13 that is based on information relating to the access token and the random number. A valid response to the challenge serves as an indication that the responding device has access to the token.
Requesting device 13 retrieves the access token from distribution proxy 14a via a secure channel (event 35). Even if requesting device 13 and distribution proxy 14a are not located in the same domain of PAN 110, a secure link can still be formed if they are virtually in the same domain, for example, via a Virtual Private Network (VPN) as described hereinbefore. Accordingly, the access token is used as a means for authenticating requesting device 13 because only devices which form part of PAN 110 can retrieve the access token from distribution proxy 14a. Other malicious devices not part of PAN 110 would not generally be capable of retrieving the access token from distribution proxy 14a.
The response from requesting device 13 (event 36) to the challenge (event 34) typically contains information derived from the random number and the access token (e.g., a cryptographic key element from the access token). The authorization controller 12a and the requesting device 13 can form a new secure channel using the key element from the access token. Thus, the access token provides a basis for authenticating requesting device 13 and authorizing requesting device 13 to access PAN 19.
The response received from requesting device 13 is processed by authorization controller 12a for verification. Authorization controller 12a is able to verify the response since authorization controller 12a also has the information key element information from the access token and the random number. Successful validation of the response results in authorization of access for requesting device 13 to PAN 19 by authorization controller 12a (event 37).
Numerous methods and algorithms exist for computing and validating the expected response. Algorithms such as SAFER+, which is described in the Specification of the Bluetooth Core System, version 1.1 and is available at URL <http://www.bluetooth.com>, may be used to compute the expected response based on the random number input and a secret key (distributed via access token) shared between authorization controller 12a and requesting device 13.
The embodiment of
An asynchronous response to challenge system or method enables authorization controller 12a to process other access requests while matching a response with a corresponding access request. However, the time duration between when authorization controller 12a issues a challenge to requesting device 13 and when a response to the challenge is received may be reduced if the pre-token is also attached to the response. This enables authorization controller 12a to more rapidly match the response with the corresponding challenge.
Referring to
As an example with reference to the embodiment shown in
Target device 43 is required to be in the same domain as, and contactable by, authorization controller 42 for the authority transfer to be processed (event 46). After processing, authorization controller 42 initiates a call to target device 43 to respond or acknowledge (event 47). Target device 43 responds by submitting an administrator ID, an administrator password and an administrator key (event 48). If the response from target device 43 is the expected response, then the authority transfer process is complete and confirmation that target device 43 is the new authorization authority for authorization controller 42 is sent to the target device 43 (event 49). The authorization controller 42 may require the target device 43 to submit a device ID in addition to the administrator ID, password and key. As the authority transfer process may be vulnerable to “sniffing” or “eavesdropping” in a wireless environment, a physical link such as a Universal Serial Bus (USB) link provides additional security for this process.
At step 51, authorization controller 12a receives an access request with an attached pre-token from a requesting device 13 and searches its token store (in memory) for an access token associated with the pre-token. If an associated access token is not located (N), at step 52, the request for access is denied at step 511.
If an associated access token is located (Y), at step 52, authorization controller 12a determines whether a security association exists between authorization controller 12a and a distribution proxy 14a for the requesting device 13, at step 53. The authorization controller 12a must have a pre-established security association with the distribution proxy 14a in order for the associated access token to be passed securely across a network.
If a security association does not exist (N), the authorization controller 12a refers back to the authorization authority 11a for resolution, at step 54. If the authorization authority 11a is able to resolve the lack of a security association (Y), processing continues at step 56. One possible way of resolving the lack of a security association is for the authorization authority 11a to instruct the authorization controller 12a to form a security association with an appropriate proxy for the requesting device 13. However, if the authorization authority 11a is unable to resolve the lack of a security association (N), the access token is revoked at step 55 and the request for access is denied at step 511.
If a security association does exist (Y), the corresponding access token is sent, at step 56, via a secure channel to the distribution proxy 14a specified by authorization authority 11a.
At step 57, authorization controller 12a issues a challenge to requesting device 13, which may optionally include a random number. A response to the challenge is received from requesting device 13, at step 58, which includes information derived from a key element from the access token and/or the random number. Any requesting device is assumed to be associated with its distribution proxy (e.g., requesting device 13 and distribution proxy 14a. Accordingly, requesting device 13 is able to securely retrieve the access token from distribution proxy 14a. Other malicious devices that do not form part of PAN 110 do not have access to distribution proxy 14a and are thus unable to retrieve the access token. A secure link can be formed between authorization controller 12a and requesting device 13 based on the access token key element. Since authorization controller 12a also has the access token key, authorization controller 12a is thus able to derive the expected response, which may also be based on the random number.
At step 59, a determination is made whether the response from the requesting device 13 is the expected response. If the response is the expected response (Y), then access is granted to requesting device 13 at step 510. If not (N), access is denied at step 511.
An access token may include elements such as validity time or duration and a validity tag for managing the lifetime of the token. A validity tag typically comprises a Boolean flag for indicating whether a related access token is valid (e.g., flag=true) or invalid (e.g., flag=false). When the validity time expires, the token is no longer valid and access is terminated. Alternatively, an authorization authority may revoke access at any point in time.
Authorization authority 11a sends an instruction to authorization controller 12a to invalidate an access token (event 61). Authorization controller 12a processes the instruction and sets the validity tag to “invalid” (event 62). Any ongoing access to PAN 19 by a device using the invalidated token is terminated. Authorization controller 12a sends an acknowledgement to authorization authority 11a when the process of revoking access for the ad-hoc user is completed (event 63).
Referring to
The communication of step 73 may be in response to a challenge sent to the requesting device and a further determination may optionally be made at step 74 whether the requesting device has received a random number issued with the challenge.
The computer software involves a set of programmed logic instructions that may be executed by the computer system 800 for instructing the computer system 800 to perform predetermined functions specified by those instructions. The computer software may be expressed or recorded in any language, code or notation that comprises a set of instructions intended to cause a compatible information processing system to perform particular functions, either directly or after conversion to another language, code or notation.
The computer software program comprises statements in a computer language. The computer program may be processed using a compiler into a binary format suitable for execution by the operating system. The computer program is programmed in a manner that involves various software components, or code, that perform particular steps of the methods described hereinbefore.
The components of the computer system 800 comprise: a computer 820, input devices 810, 815 and a video display 890. The computer 820 comprises: a processing unit 840, a memory unit 850, an input/output (I/O) interface 860, a communications interface 865, a video interface 845, and a storage device 855. The computer 820 may comprise more than one of any of the foregoing units, interfaces, and devices.
The processing unit 840 may comprise one or more processors that execute the operating system and the computer software executing under the operating system. The memory unit 850 may comprise random access memory (RAM), read-only memory (ROM), flash memory and/or any other type of memory known in the art for use under direction of the processing unit 840.
The video interface 845 is connected to the video display 890 and provides video signals for display on the video display 890. User input to operate the computer 820 is provided via the input devices 810 and 815, comprising a keyboard and a mouse, respectively. The storage device 855 may comprise a disk drive or any other suitable non-volatile storage medium.
Each of the components of the computer 820 is connected to a bus 830 that comprises data, address, and control buses, to allow the components to communicate with each other via the bus 830.
The computer system 800 may be connected to one or more other similar computers via the communications interface 865 using a communication channel 885 to a network 880, represented as the Internet. Multiple communications interfaces may also be practised, for example, to additionally connect to a Personal Area Network (PAN).
The computer software program may be provided as a computer program product, and recorded on a portable storage medium. In this case, the computer software program is accessible by the computer system 800 from the storage device 855. Alternatively, the computer software may be accessible directly from the network 880 by the computer 820. In either case, a user can interact with the computer system 800 using the keyboard 810 and mouse 815 to operate the programmed computer software executing on the computer 820.
The computer system 800 has been described for illustrative purposes. Accordingly, the foregoing description relates to an example of a particular type of computer system such as a personal computer (PC), which is suitable for practicing the methods and computer program products described hereinbefore. Those skilled in the computer programming arts would readily appreciate that alternative configurations or types of computer systems may be used to practise the methods and computer program products described hereinbefore. For example, the methods and computer program products described hereinbefore may be practised using computer platforms including static and mobile computer systems, handheld computers such as a Personal Digital Assistant (PDA) and mobile telephones.
Appendix 1, hereinafter, contains examples of messages, instructions and tokens generated in XML format in accordance with an embodiment of the present invention.
The foregoing detailed description provides exemplary embodiments only, and is not intended to limit the scope, applicability or configurations of the invention. Rather, the description of the exemplary embodiments provides those skilled in the art with enabling descriptions for implementing an embodiment of the invention. Various changes may be made in the function and arrangement of elements without departing from the spirit and scope of the invention as set forth in the claims hereinafter.
Where specific features, elements and steps referred to herein have known equivalents in the art to which the invention relates, such known equivalents are deemed to be incorporated herein as if individually set forth. Furthermore, features, elements and steps referred to in respect of particular embodiments may optionally form part of any of the other embodiments unless stated to the contrary.
Messages, instructions and tokens described hereinbefore can, for example, be generated in XML format. However, such may alternatively be generated using another format having similar parameters for passing information. Furthermore, XML encryption can be used to encrypt the messages, instructions and tokens to provide additional security to that provided by a secured channel.
The examples in this appendix relate to messages, instructions and tokens generated in XML format in accordance with a specific embodiment of the present invention. Accordingly, the structures and parameters of the messages, instructions and tokens in this appendix are intended as examples only and are not intended to limit the scope of the present invention.
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/SG05/00181 | 6/7/2005 | WO | 00 | 5/27/2008 |
