Patent Application
20060059344
In general, the present invention relates to service authentication, and in particular to a communication system comprising user equipments and a communication network system, in which a user equipment performs authentication with the communication network system by using passwords.
Passwords will provide the most widely accepted authentication method for the foreseeable future. Password based authentication will be readily available independently of network and device technologies. The password security and management should be improved to reach the largest possible user base without authentication being the bottleneck for launching new services in mobile networks. Recently mobile operator's WLAN (Wireless Local Area Network) and xDSL (Digital Subscriber Line) authentication and access independent use of IMS (IP Multimedia Subsystem) and PoC (Push to talk over Cellular) services have suffered from strong coupling between the authentication, access network and terminal technologies.
It is an object of the invention to provide an effective password delivery in communication systems.
According to an aspect of the invention, this object is achieved by receiving key information for calculating at least one password by a user equipment from a communication network system via a secure channel, generating at least one password on the basis of the key information in the user equipment, and performing authentication between the user equipment and the communication network system using the at least one password.
According to an embodiment of the invention, to minimize the SMS (Short Message Service) load that a conventional http digest password delivery causes, a Seed and Hash Approach is used. An entity in the communication network system, e.g. an operator's own service management system with a terminal management server generates the seed and optionally a (new) secret key, and sends it/them to the user equipment or terminal over SMS. The service management system generates and sends a new seed (and secret key) to the terminal after the number of generated passwords reaches a configurable threshold or a timeout expires.
Requiring a subscriber to enter a PIN code before applying the hash function enhances the security of the mechanism. Applying different seeds, secret keys and/or hash functions can create password domains.
Minimal SMS load on a PoC password delivery is a relevant use case. Other operator's applications can use the same mechanism with possibly separate password spaces. Even a third party service provider can deliver the information for generating the one-time passwords over SMS or from a (TLS (Transport Layer Security) protected) web page.
The invention minimizes the SMS load in PoC password delivery. Other applications in addition to PoC can use the delivered passwords as well. The passwords are access and terminal technology independent authentication mechanism. Conventional authentication may have suffered from lack of SIM (Subscriber Identity Module) support, or slow deployment of SIM smartcards. The secure password delivery over SMS or some other trusted channel (HTTP (HyperText Transport Protocol)/TLS) according to the invention removes this obstacle altogether benefiting all the future applications.
Often the mobile operator's control over the smartcards and authentication is considered too strong. According to the invention, passwords are not dependent on any smartcard and therefore there is more freedom in selecting alternative trust providers for the terminals.
The terminal and the server must use the passwords in synchronism. For this purpose, the server may advise the terminal about a correct next password id. Alternatively, the server may allow a sliding window of passwords so that the N closest passwords are allowed in addition to the correct one. As the last resort the terminal can request a new seed to re-synchronize.
As the one-time passwords do not provide mutual authentication, e.g. server certificates may be used for this purpose.
The present invention is concerned with password usage for enabling multi-access and multi-terminal use cases. Passwords provide the most widely accepted authentication method when considering all Internet access and terminal technologies in use today. Recent development in WLAN authentication and PCs may bring smartcard-based authentication to a wider variety of terminals in the future, but nevertheless the password authentication does not show any signs of being displaced. From the network business perspective it is desirable that a trusted channel can be used without any mobile operator involvement, but the home operator can add value with some additional function or improved security.
Password based authentication will be readily available independently of the network and device technologies. In the following it will be described how password security and management can be improved to reach the largest possible user base without authentication being the bottleneck for launching new services. The design philosophy is “always use the cellular network as the trusted channel for password management” (rather than the conventional one “always use the xSIM as the trusted authentication token”). In general the password management consists of:
One-time passwords (OTP) can be used only once as the name indicates. Thus the change step above is not needed at all. Revocation may be needed depending on the value of the service. OTPs may be delivered as a list of random numbers, which the user must store securely. Another mechanism uses a secret pass-phrase to generate a sequence of one-time (single use) passwords.
In IP Multimedia core access authentication operator's own service management system with a terminal management server should be able to support OMA (Open Mobile Alliances) OTA (Over The Air) and PoC industry standard based access authentication method including secure password delivery logistics. However, this creates a lot of SMS traffic, which cannot necessarily be charged by the operator. SMS delivery is not instant and it is not guaranteed. This increases probability to end up in a situation where the terminal and network have different passwords, which decreases usability from end users' point of view.
Several operating systems including Windows NT force the user to change the password after a regular time interval. The user can select a weak password and typically the interval is quite long.
Known S/Key and OTP mechanisms generate a sequence of passwords by applying a hash function to a seed, secret key and the previous password.
Moreover, it has been proposed that SIM based IMS (IP Multimedia Subsystem) terminals will use shared secret based http digest authentication mechanism. The passwords as well as IMPI (IP Multimedia Private Identity) and IMPU (IM Public Identity) have to be delivered into a memory of the mobile terminal to be used later with SIP (Session Initiation Protocol) authentications. Because these stored passwords are targeted for IMS authentication, end-users should not be able to see them during the delivery or after the delivery. The proposed approach is that the service management system will have capabilities to generate these passwords automatically for end-users when requested. The service management system should then store the password and deliver it also to the mobile terminal in question. The delivering could happen via a terminal management server by using smart messages. However the delivery mechanism should be such that an end-user is not able to see the password in question. In case of USIM (User Service Identity Module) or ISIM (IM Services Identity Module) use in new terminals, IMS AKA authentication based on shared secret (K) is used.
Furthermore it has been proposed how the RAND challenges can be split to different domains to avoid their usage in an incorrect context. E.g. GSM (Global System for Mobile communications) and GPRS (General Packet Radio Services) may have separate RAND spaces. The present invention describes mechanisms to split the password domains.
The present invention focuses mainly on decreasing the amount of SMS traffic. Usability in the case of out of sync passwords and detecting malicious users are secondary concerns.
The password delivery according to the present invention to be described in the following involves at least a UE (User Equipment) and one or more network elements, which accept the password. Network elements may also generate the passwords since user selected ones are typically too weak for subscriber (charging) security. (It is to be noted here that the password management is different from the password usage.)
The user equipment 10 comprises a receiving block 11, a generating block 12 and an authenticating block 13. The user equipment 10 may further comprise a deleting block 14 and an updating block 15. The receiving block 11 receives key information for calculating at least one password from the communication network system via a secure channel. The key information may comprise a long-term secret key of the user equipment. The secure channel may be an SMS message or encrypted IPSec or TLS connection. The key information may be received from the first network entity 220 acting as subscription management entity.
The generating block 12 generates the at least one password on the basis of the received key information, and the authenticating block performs authentication with the communication network system, e.g. the second network entity 230 acting as authentication proxy using the generated password.
The first network entity 220 includes a generating block 221 and a sending block 222. It may further include a receiving block 223, a deleting block 224 and a detecting block 225. The generating block 221 generates key information for the user equipment 10, and the sending block 222 sends the key information to the user equipment 10 via the secure channel.
The second network entity 230 comprises a sending block 231, a receiving block 232 and an authenticating block 233. It may further comprise a deleting block 234, a detecting block 235, an updating block 236 and generating block 237. The sending block sends a request for generating a password to the user equipment 10 in case the user equipment 10 requests a service. The request includes encryption data for generating at least one password in the user equipment 10. The encryption data may have been generated by the generating block 237. The encryption data may comprise not confidential data and may comprise a server's key, which is different for each server, and a number N of secure hash runs needed to generate a next OTP (One-Time Password). When the receiving block 232 receives the password generated on the basis of the encryption data from the user equipment 10, the authenticating block 233 verifies the password.
The generating block 12 of the user equipment 10 may generate the password on the basis of a combination of the key information and the encryption data. In generating the password a secure hash function may be applied to the combination of the key information and the encryption data.
The receiving block 11 of the user equipment 10 may receive a request for generating a password from the communication network system 200, e.g. the second network entity 230 acting as authentication proxy, the request including encryption data, and the generating block 12 of the user equipment 10 may generate the password in response to the request using the key information and the encryption data included in the request.
The receiving block 11 of the user equipment 10 may receive a revocation request for revoking a password from the communication network system, i.e. the first network entity 220 or the second network entity 230. In response thereto the deleting block 14 may delete the key information and the encryption data used for the password generation. If the first network entity 220 sent the revocation request, the deleting block 14 may delete all the key information and encryption data. If the second network entity 230 sent the revocation request, the deleting block 14 may delete only the encryption data related to that particular network entity.
Also the user equipment 10 may contain a detection block (not shown), which automatically triggers key deletion. E.g. smartcards can erase the key material if they detect suspicious activity like changes in the input voltage, etc.
For synchronizing purposes, the updating block 15 of the user equipment 10 may decrease a count value (N) indicating validity of the encryption data with every password calculation. The decrement may be one or more.
The receiving block 223 of the first network entity 220 may receive a request for generating a password from the second network entity 230 acting as service management entity of the communication network system 200, the request including encryption data. In response thereto the generating block 221 of the first network entity 220 may generate a password using the generated key information and the received encryption data, and the sending block 222 of the first network entity 220 sends the password to the second network entity 230.
In case the detecting block 224 of the first network entity 220 detects a non-permitted use of the user equipment 10, the deleting block 224 of the first network entity 220 may delete the key information, and the sending block 222 of the first network entity 220 sends a revocation request to the user equipment 10. The sending block 222 of the first network entity 220 also sends a revocation request to the second network entity 230 so that it may delete the encryption data related with the this particular user equipment 10.
Although
As mentioned above, the sending block 231 of the second network entity 230 may send the request for generating a password to the first network entity 220 acting as subscriber management entity of the communication network system 200. In this case, the receiving block 232 of the second network entity 230 may receive the password from the first network entity 220, and the authenticating block 233 may verify the password received from the user equipment 10 on the basis of the password received from the first network entity 220.
In case the authentication block 233 of the second network entity 230 does not verify the password from the user equipment 10, the sending block 231 may re-send a request for generating a password to the user equipment 10, the request including updated encryption data.
In case the detecting block 235 of the second network entity 230 detects a non-permitted use of the user equipment 10, the deleting block 234 may delete the password received from the user equipment 10 and the sending block 231 of the second network entity 230 sends a revocation request to the user equipment 10.
For synchronizing purposes the updating block 236 may decrease a count value.(N) indicating the validity of the encryption data with every password received from the user equipment 10. The second network entity 230 may indicate the correct count value (N) to the User Equipment 10.
It is to be noted that
Alternatively, operations performed in one block may be further separated into sub-blocks.
The operations performed in the blocks shown in
In the following an embodiment of the invention will be described which is based on OTP (One-Time Password) architecture.
As it will be seen from the following description, in the one-time password schemes the use of a one-way function (“hash”) is essential to the security. The hash function h( ) will be run several times on the encryption data to get the current key, e.g.:
Public key certificates provide similar properties, but the required Public Key infrastructure is complex and expensive. OTP focuses on authentication only and in the mobile environment its small messages with few attributes are an advantage.
It is to be noted that authentication proxies (APs) as shown in
The relationships between the domains shown in
A user equipment UE shown in
The SuMa generates the K on behalf of the user. It also calculates the first expected response for the AP and stores the association between UE and AP, which will be described below. The SuMa does not participate subsequent authentications or the use of the service. The SuMa may send a key revocation command to the UE and AP. The SuMa may store key material for backup purposes. During revocation the stored keys must be deleted. The SuMa may assist in re-synchronizing UE and AP in case of a corrupted OTP, xOTP or N at either end. N is the number of secure hash runs needed to generate the next OTP, and xOTP is the expected hash of the next OTP that will be described in greater detail below.
The AP authenticates the UE when accessing the service. It generates the seed to initiate the OTP sequence. As described in greater detail below the AP requests the first OTP from the SuMa since it does not know K and therefore cannot verify the first OTP. On successful authentication the AP stores the OTP. The AP can verify the subsequent OTPs based on the stored OTP during later authentications without assistance from the SuMa. On revocation the AP deletes the stored OTP.
Using the OTP standard terminology, the UE is the generator and the AP is the server. The Subscription management SuMa generates the secret key K (pass phrase) on the user's behalf. The server generates the seed. Any entity may initiate key revocation.
Referring to
The UE and the SuMa have mutually authenticated before the OTP delivery starts. The communication channel must be a secure channel, e.g. SMS or an encrypted channel. The SuMa and the authentication proxy AP share a (semi-) permanent security association, and encrypted communication channel (e.g. IPSec VPN). E.g. a TLS handshake procedure with a server certificate will provide the secure channel, and a similar operation is possible with IKE (Internet Key Exchange) or IKEv2 as well. A TLS, IKE or IKEv2 standard may be modified to take the usage of one time passwords into account. Another alternative is to keep the TLS or IPSec channel only “half authenticated” (i.e. client verifies server identity), and authenticate the client on top of that channel.
Steps 4 to 7 in
In step 1 in
In step 2 in
In step 3 in
In step 4 in
In step 4a in
In an initial step (steps 5 and 5a in
In a computation step (step 6 in
As can be seen from step 6a in
In steps 7 and 7a in
The AP has a database containing, for each user, the one-time password xOTP of a newly initialized sequence (the pseudo-predecessor). To authenticate the user, the AP runs the OTP received from the UE through the secure hash function d times (step 8 in
In steps 9 in
In step 10, the SuMa deletes the seed and N parameters from the authentication proxy. This is to prevent external attackers or malicious insiders at SuMa from masquerading as UE.
After a successful authentication the UE and AP share the OTP, which will be used for verifying the response to the next authentication. S can be used N-1 times before generating a new seed. Any party may decide to use S fewer times and revoke it earlier due to local policy or on suspicion of fraud as described below.
Referring to
The AP has stored xOTP from the previous successful authentication. It will be used for verifying the response to the next authentication. S can be used N-1 times before generating a new seed. As described above, any party may decide to use S fewer times and revoke it earlier due to local policy or on suspicion of fraud.
In step 1 in
In step 2 in
In the computation step (step 3 in
In step 4 in
The AP has a database containing, for each user, the one-time password xOTP of the previous authentication. To authenticate the user, the AP runs the OTP received from the UE through the secure hash function once (step 5 in
In steps 6 in
According to
However, in step 5 in
Thus, in step 6 in
An eavesdropper cannot use the N information alone to forge OTP. An active attacker could cause denial of service at most. After synchronization the user will resend the request and authenticate successfully.
Additional heuristics may be used at the AP end to limit the notifications to probable honest UEs: if the AP stores a couple of most recent OTPs, it can check if OTP matches any of those, and send notification only if it did. This blocks notifications to attackers who pick up OTP randomly.
However, in step 5 in
Thus, in step 6 in
Referring to FIGS. 8 to 10 in the following the OTP revocation procedure will be described.
To minimize the SMS load that the http digest password delivery causes, as described above an embodiment of the invention uses the seed and hash approach. The communication network system generates the seed and optionally a new secret key, and sends at least the secret key to the user equipment over SMS. It is also possible to use a fixed secret key for all subscribers or one key for a group of one or more subscribers. The hash function generates the first password from the seed and the secret key, and a configurable number of further passwords. The later passwords do not require short messages. The passwords are used in the reverse order. In other words, the last generated one is used first to prevent eavesdroppers from calculating the rest of the password sequence.
The communication network system generates and sends a new seed (and secret key) to the user equipment after the number of generated passwords reaches a configurable threshold or a timeout expires. It is also possible that the user equipment requests a new seed (and secret key).
Requiring the subscriber to enter a PIN (Personal Identification Number) code before applying the hash function can enhance the security of the mechanism. The PIN is a local locking mechanism that the user equipment or terminal, SIM or UICC enforces. PIN query may be used for generating the first password from the seed or for generating any of the later passwords. The password itself will remain invisible to the subscriber.
Applying different seeds, secret keys and/or hash functions can create password domains. The domain specific password sequences can be independent or rely on a common master sequence. Domain specific sequences for applications a and b diverge from the beginning (like twigs from the root of a bush):
pwd-a(0):=hash (seed, key-a)
pwd-a(1):=hash (pwd-a(0), key-a)
. . .
pwd-b(0):=hash (seed, key-b)
pwd-b(1):=hash (pwd-b(0), key-b)
A master sequence may provide a better synchronization point for the application passwords (like a bole where the branches attach):
pwd-m(0):=hash (seed, key-m)
pwd-m(1):=hash (pwd-m(0), key-m)
. . .
pwd-a(0):=hash (pwd-m(0), key-a); first branch
pwd-a(1):=hash (pwd-a(0), key-a)
pwd-a(2):=hash (pwd-a(1), key-a)
pwd-a(3):=hash (pwd-a(2), key-a)
pwd-a(4):=hash (pwd-m(1), key-a); second branch
pwd-a(5):=hash (pwd-a(4), key-a)
. . .
pwd-b(0):=hash (pwd-m(0), key-b); first branch
pwd-b(1):=hash (pwd-m(1), key-b); the branches are real short—they all start from the bole
pwd-b(2):=hash (pwd-m(2), key-b)
pwd-b(3):=hash (pwd-m(3), key-b)
pwd-b(4):=hash (pwd-m(4), key-b)
pwd-b(5):=hash (pwd-m(5), key-b)
. . .
It is to be understood that the above description of the preferred embodiments is illustrative of the invention and is not to be construed as limiting the invention. Various modifications and applications may occur to those skilled in the art without departing from the true spirit and scope of the invention as defined by the appended claims.
| Number | Date | Country | Kind |
|---|---|---|---|
| EP 04 021 602.0 | Sep 2004 | EP | regional |
