GB2456499A

GB2456499A - Transport layer authentication

Info

Publication number: GB2456499A
Application number: GB0720299A
Authority: GB
Inventors: Nicholas Bone
Original assignee: Vodafone Group PLC
Current assignee: Vodafone Group PLC
Priority date: 2007-10-17
Filing date: 2007-10-17
Publication date: 2009-07-22
Anticipated expiration: 2027-10-17
Also published as: GB2456499B; GB0720299D0

Abstract

A method and system for maintaining access control for a secure web server, SCWS. Protection sets (each defining a group of protected resources, a realm of logical users who are granted access to the protected resources, and instructions for authenticating the users in that realm) are stored by the web server so that upon receiving a request to access a given protected resource, the web server assesses the parameters of the protection set associated with the given protected resource and selects an appropriate cryptographic ciphersuite for use in securing sessions to access that protected resource.

Description

2456499

TRANSPORT LAYER AUTHENTICATION

The present invention relates to a method for determining an appropriate ciphersuite for use in transport layer security.

5 The Smart Card Web Server (SCWS) is a technology standardized by the Open

Mobile Alliance (OMA) to allow smart cards used in mobile telecommunications (i.e. subscriber identity module (SIM) cards) to support an HTTP web server. Details of the technology may be found in "OMA Smartcard-Web-Server", OMA-TS-Smartcard_Web_Server-Vl_0-20070209-C, Candidate Version 1.0 - 09 Feb 2007, JO published on the OMA website.

The SCWS supports secure HTTP (HTTPS) operations. The Transport Layer Security (TLS) protocol, and related Secure Sockets Layer (SSL) protocol, are the protocols that provide HTTPS for Internet transactions between Web browsers and Web servers. In the context of the SCWS, use of TLS (in HTTPS) adds several security 15 benefits such as encrypting and integrity-protecting the traffic between a terminal application and the smart card. Importantly, it also allows the smart card to authenticate the client i.e. the terminal application and/or the human being behind it.

However, there are several possible authentication techniques: the client could be authenticated with a weak username and password, or by a strong pre-shared key 20 (PSK), or by a client X.509 certificate. TLS also supports several possible methods for establishing and using session keys: for brevity, the exact method is referred to hereafter as the "TLS ciphersuite".

Which authentication technique is used will impact on what TLS ciphersuite should be selected by the SCWS when a given HTTPS URL is requested. If the SCWS 25 makes the wrong decision then either the connection will fail needlessly or security may be compromised. To compound the issue, the SCWS is on a system (a smart card) with limited facilities by comparison to a typical PC, so the SCWS needs a way of choosing the correct ciphersuite (and successfully authenticating the client) quickly.

It is therefore an object of the invention to obviate or at least mitigate the 30 aforementioned problems.

In accordance with one aspect of the present invention, there is provided a method for maintaining access control for a secure web server, the method including, in

the web server: storing a plurality of protection sets, each protection set defining a group of protected resources, a realm of logical users who are granted access to the protected resources, and instructions for authenticating the users in that realm; receiving a request to access a given protected resource; and selecting an appropriate 5 cryptographic ciphersuite for use in securing sessions to access any given protected resource, the selection of ciphersuite being determined by the parameters of the protection set associated with the given protected resource.

The invention thus provides a method for managing the efficient selection of TLS ciphersuites via the use of "protection sets", which are defined in the 10 aforementioned OMA SmartCard Web Server specification.

In order to understand the invention in more detail it is worth expanding upon the term "protection set" adopted in the SCWS standard. This term refers to a set of security parameters that need to be satisfied to access a protected resource, where a resource is any web-page that might be requested from the web-server. Any individual 15 URI or URI sub-tree (e.g. http://mybankpages/...) can be linked to a protection set. The protection set to which a URI is linked, defines how to access this URI (or sub-tree).

Within the OMA SCWS specification, pages can be protected with HTTPS, or with user authentication (which is either HTTP basic or HTTP digest authentication) or with both. The 'protocol' parameter defines whether https is needed or whether http is 20 sufficient. The 'realm' parameter specifies a collection of 'user' accounts, each of which must be created via a special "Define User" command, which defines the username and 'password' credentials for that account. The user account is then added to a realm via the "Add User" command. Where a realm is defined, then the resources covered by the protection set can only be accessed by corresponding users in that realm, who must 25 present the associated account credentials.

The method of this invention preferably includes extending OMA SCWS protection sets to incorporate additional authentication steps. Protection sets can be specified as requiring pre-shared key (PSK) authentication or certificate authentication of the ME client, as an alternative to user+password authentication. 30 In accordance with a further aspect of the invention there is provided a system for maintaining access control for a secure web server, the system including a protection set store, which in operation stores a plurality of protection sets, each protection set

2

defining a group of protected resources, a realm of logical users who are granted access to the protected resources, and instructions for authenticating the users in that realm; the system further including means for receiving a request to access a given protected resource; and a processing means which operates to select an appropriate cryptographic 5 ciphersuite for use in securing sessions to access any given protected resource, the selection of ciphersuite being determined by the parameters of the protection set associated with the given protected resource.

In the case where PSK authentication is specified, the "Users" in realms can be implicitly associated with strong PSKs already stored on card, by equating the "user" 10 field with a PSK identifier. The SCWS will then allow access to the protected resource only through a pure PSK TLS ciphersuite. Alternatively, users are created explicitly via the "Define User" command, with the "password" field acting as a weak pre-shared key. The SCWS will then allow access to the protected resource only through a mixed TLS ciphersuite (based on PSK + public key).

15 In the case where certificate authentication is specified, users can again be created explicitly via the "Define User" command, by setting the "password" field to a public key value. The SCWS will then allow access to the protected resource only through a pure public key ciphersuite, but as an optimisation the SCWS does not need to parse the client certificate.

20 The strength and type of the authentication method can thus be linked to the appropriate ciphersuite to be used when setting up the TLS session.

In a specific embodiment of the invention, the appropriate ciphersuite for use in the transport layer security session is determined as follows:

25 1. The mechanism of SCWS "protection sets" is extended to allow an

SCWS administrator to tell the SCWS that certain "users" are supposed to be authenticated by pre-shared key or certificate, instead of by username/password. (Preferably, the administrator can also specify exactly which pre-shared key or certificate the client needs to be using, and can indicate whether the pre-shared key is 30 "strong" or "weak").

2. When an HTTPS URL is requested, the SCWS looks up which administrator is responsible for the security of that URL, and which protection set

3

applies (if any). By the type of user authentication specified in the protection set, the SCWS then knows which ciphersuite it needs to select and enforce: whether that be one which will allow use of a username/password, or a weak pre-shared key, or a strong pre-shared key, or a certificate.

5 Knowing that a pre-shared key or a certificate should be used, the SCWS can use the additional information that was (preferably) provided by the administrator to determine exactly which secret or certificate to use: this then speeds up key negotiation/certificate exchange and parsing etc, saving time and processing costs.

This means that the SCWS on SIM cards can deploy TLS easily with no security 10 mistakes, and less stringent processing requirements. This enables the fast use of services with very sensitive User Interface requirements driving the need for TLS (such as the need to encrypt a personal identification number (PIN) or user display information).

By requiring the use of HTTPS (rather than HTTP), the SCWS can be used to 15 control client (and also administrator) access to data stored on the smart card (i.e. the UICC or SIM card). The control is enforced as follows:

Secure client authentication need not always be established when the HTTPS session is set up. The SCWS can simply treat the client as anonymous when establishing the HTTPS session, and require subsequent authentication of the client within the 20 communication session e.g. via a normal PIN or password.

However, client authentication can also be done transparently (i.e. without the user being aware) when the HTTPS session is first set up. When such HTTPS client authentication is used, authentication may be via preshared key (this is effectively an authentication of the client's application rather than the client himself). Alternatively, 25 authentication may be achieved by ensuring that both client and server have digital certificates which can be recognized and accepted, by the server and client respectively.

The SCWS, UICC and handset browser (and optionally other handset applications like MIDlets) support preshared secret keys for TLS use as described in the OMA Standard. The SCWS supports TLS_PSK_WITH_AES_128_CBC_SHA 30 according to RFC 4279. Connections are allowed by the UICC with this cipher suite only when the corresponding protection set specifies PSK authentication, and only when the UICC already has a strong (i.e. high-entropy) pre-shared secret available to

4

authenticate the ME client (browser and optionally MIDlet), for instance a secret established and labelled using the mechanisms described in 3GPP TS 33.110 rel 7 and ETSI TS 102 484 Rel. 7.

The SCWS (UICC), handset browser (and optionally other handset applications 5 like MIDlets) also support TLS_RSA_WITH_AES_128_CBC_SHA according to RFC 4279. Connections are allowed by the UICC with this cipher suite only when the corresponding protection set specifies certificate authentication, or username+password authentication or no client authentication at all. This cipher suite is therefore used when the handset client application (browser and optionally MIDlet) does not have a shared 10 secret to authenticate itself to the UICC. The ME client is instead authenticated by a TLS Client Certificate, or else unauthenticated at the TLS level.

The SCWS (UICC and handset) may also be arranged to support the following additional PSK-TLS ciphersuites defined in RFC 4279 (the UICC supporting at least one; the handset supporting both):

15 • TLS_DHE_PSK_ WITH_ AES_ 12 8_CBC_S HA

TLS_R S A_PS K_ WITH_AES_ 128_CBC_S HA The SCWS does not need to negotiate and parse which shared secret is used by the client, as the protection set already provides sufficient information about which secret the client will be using.

20 Connections are allowed by the UICC with these cipher suites only when the corresponding protection set specifies PSK authentication, and when the associated preshared key has been identified to the UICC as a "weak" key. These cipher suites are therefore used when the handset client application (browser and optionally MIDlet) has only a weak (i.e. low entropy) pre-shared secret to authenticate itself to the UICC, for 25 instance a password that is manually entered into the ME client by the user.

For technical reasons, the SCWS will always require a certificate itself when acting as the server for TLS_RSA_WITH_AES_128_CBC_SHA or TLS_RSA_PSK_WITH_AES_128_CBC_SHA. This server-side certificate need not be used for authentication of the UICC, just for the establishment of a TLS channel with 30 the above mentioned cipher suites.

5

The SCWS thus does not need to parse the certificate presented by the client, as the protection set already provides sufficient information about which key the client will be using.

The UICC is preferably capable of presenting a self-signed certificate. This 5 certificate will be generally inserted into the UICC at production, along with the corresponding private key. It could however be created and signed onboard if the corresponding keypair is generated onboard. Alternatively, the UICC can be arranged to present another certificate inserted into the UICC at production.

Conveniently, the handset client application (browser and optionally MIDlet) 10 will allow and accept a self-signed certificate presented by the SCWS, for either of TLS_RSA_WITH_AES_128_CBC_SHA or

TLS_RSA_PSK_WITH_AES_128_CBC_SHA. In such cases, the handset implementation will implicitly authenticate the UICC by robust terminal implementation of the SCWS, rather than by reliance on a trusted certificate.

15

6

Claims

CLAIMS:

1. A method for maintaining access control for a secure web server, the method including, in the web server:

5 storing a plurality of protection sets, each protection set defining a group of protected resources, a realm of logical users who are granted access to the protected resources, and instructions for authenticating the users in that realm;

receiving a request to access a given protected resource; and selecting an appropriate cryptographic ciphersuite for use in securing sessions to 10 access any given protected resource, the selection of ciphersuite being determined by the parameters of the protection set associated with the given protected resource.

2. The method of claim 1 wherein the secure web server is implemented within a component of a mobile terminal.

15

3. The method of claims 1 or 2 wherein the secure web server is implemented within a removable storage device.

4. The method of claim 3 wherein the storage device is a smart card.

20

5. The method of any of the preceding claims wherein the secure web server is a Smart Card Web Server.

6. The method of any of claims 1 to 5 wherein at least one of the logical users is a 25 human user.

7. The method of any of claims 1 to 5 wherein at least one of the logical users is a client device.

30 8. The method of any of claims 1 to 5 wherein at least one of the logical users is a client application.

7

9. The method of any of claims 1 to 8 wherein at least one of the protected resources is a URI or URI tree.

10. The method of any one of the preceding claims wherein the protection sets are 5 managed by at least one administrator.

11. The method of claim 10 wherein said at least one administrator also provides information about the exact credentials for authenticating the logical users.

10 12. The method of any one of the preceding claims, wherein the step of selecting a ciphersuite prior to the establishment of the secure session includes determining whether at least one of the protection sets specifies that the logical users are to be authenticated by a strong pre-shared key.

15 13. The method of claim 12, the method further including automatically selecting a ciphersuite that requires pure pre-shared key authentication, when at least one resource protected by one of the protection sets is requested.

14. The method of claim 13 wherein the automatically selected ciphersuite is 20 TLS_PSK_WITH_AES_128_CBC_SHA.

15. The method of any one of claims 1 to 11, wherein the step of selecting a ciphersuite prior to the establishment of the secure session includes determining whether the logical users are to be authenticated by a weak pre-shared key, with the

25 authentication to be conducted when establishing the secure session.

16. The method of claim 15, the method further including automatically selecting a ciphersuite that requires a mixture of pre-shared key and public key authentication, when at least one resource protected by one of the protection sets is requested.

30

17. The method of claim 16 wherein the automatically selected ciphersuite is TLS_DHE_PSK_WITH_AES_128_CBC_SHA.

8

18. The method of claim 16 wherein the automatically selected ciphersuite is TLS_RSA_PSK_WITH_AES_128_CBC_SHA.

5 19. The method of any one of claims 1 to 11, wherein the step of selecting a ciphersuite prior to the establishment of the secure session includes determining whether the logical users are to be authenticated by certificate, with the authentication to be conducted when establishing the secure session.

10 20. The method of claim 19, the method further including automatically selecting a ciphersuite that requires certificate-based client authentication, when at least one resource protected by one of the protection sets is requested.

21. The method of claim 20 wherein the automatically selected ciphersuite is 15 TLS_RSA_WITH_AES_128_CBC_SHA and wherein the method further includes requiring the TLS client to present a certificate.

22. The method of any of claims 1 to 11, wherein the step of selecting a ciphersuite prior to the establishment of the secure session includes determining whether the logical

20 users are to be authenticated by username + password, with the authentication to be conducted within a secure web session, but not when establishing the secure session.

23. The method of any of claims 1 to 11, wherein the step of selecting a ciphersuite prior to the establishment of the secure session includes determining that logical users

25 do not need to be authenticated at all.

24. The method of claims 22 or 23, the method further including automatically selecting a ciphersuite that requires no client-side authentication, when at least one resource protected by one of the protection sets is requested.

30

25. The method of claim 24, wherein the automatically selected ciphersuite is TLS_RSA_W1TH_AES_128_CBC_SHA.

9

26. The method of any one of claims 12 to 25, the method further including presenting a self-signed certificate in order to establish the secure session.

5 27. The method of any one of claims 12 to 25, wherein the client application authenticates the secure web server implicitly, thereby removing reliance on a trusted certificate.

28. A system for maintaining access control for a secure web server, the system 10 including a protection set store, which in operation stores a plurality of protection sets, each protection set defining a group of protected resources, a realm of logical users who are granted access to the protected resources, and instructions for authenticating the users in that realm;

the system further including means for receiving a request to access a given 15 protected resource; and a processing means which operates to select an appropriate cryptographic ciphersuite for use in securing sessions to access any given protected resource, the selection of ciphersuite being determined by the parameters of the protection set associated with the given protected resource.

20 29. The system of claim 28 wherein the secure web server is implemented within a component of a mobile terminal.

30. The system of claim 29, wherein the component is removable.

25 31. The system of claim 29 or 30 wherein the component is a storage device.

32. The system of claim 31 wherein the storage device is a smart card.

33. The system of any one of claims 28 to 32, wherein the secure web server is a 30 Smart Card Web Server.

10

34. The system of any one of claims 28 to 33, wherein at least one of the logical users is a human user.

35. The system of any one of claims 28 to 33 wherein at least one of the logical 5 users is a client device.

36. The system of any one of claims 28 to 33 wherein at least one of the logical users is a client application.

10 37. The system of any one of claims 28 to 36 wherein at least one of the protected resources is a URI or URI tree.

38. The system of any one of claims 28 to 37, wherein the protection sets are managed by at least one administrator.

15

39. The system of claim 38 wherein said at least one administrator also provides information about the exact credentials for authenticating the logical users.

40. The system of any one of claims 28 to 39, wherein at least one of the protection 20 sets specifies that the logical users are to be authenticated by a strong pre-shared key,

with the authentication to be conducted when establishing the secure session.

41. The system of claim 40 wherein the secure web server automatically selects a ciphersuite that requires pure pre-shared key authentication, when at least one resource

25 protected by one of the protection sets is requested.

42. The system of claim 41 wherein the secure web server automatically selects the TLS ciphersuite TLS_PSK_WITH_AES_128_CBC_SHA.

30 43. The system of any one of claims 28 to 39, wherein at least one of the protection sets specifies that the logical users are to be authenticated by a weak pre-shared key, with the authentication to be conducted when establishing the secure session.

11

44. The system of claim 43 wherein the secure web server automatically selects a ciphersuite that requires a mixture of pre-shared key and public key authentication, when at least one resource protected by one of the protection sets is requested.

5

45. The system of claim 44 wherein the secure web server automatically selects the TLS ciphersuite TLS_DHE_PSK_WITH_AES_128_CBC_SHA.

46. The system of claim 44 wherein the secure web server automatically selects the 10 TLS ciphersuite TLS_RSA_PSK_WITH_AES_128_CBC_SHA.

47. The system of any one of claims 28 to 39, wherein at least one of the protection sets specifies that the logical users are to be authenticated by certificate, with the authentication to be conducted when establishing the secure session.

15

48. The system of claim 47 wherein the secure web server automatically selects a ciphersuite that requires certificate-based client authentication, when at least one resource protected by one of the protection sets is requested.

20 49. The system of claim 48 wherein the secure web server automatically selects the TLS ciphersuite TLS_RSA_WITH_AES_128_CBC_SHA and also requires the TLS client to present a certificate.

50. The system of any one of claims 28 to 39, wherein at least one of the protection 25 sets specifies that the logical users are to be authenticated by username + password,

with the authentication to be conductcd within a secure web session, but not when establishing the secure session.

51. The system of any one of claims 28 to 39, wherein at least one of the protection 30 sets specifies that logical users do not need to be authenticated at all.

12

52. The system of claim 50 or claim 51, wherein the secure web server automatically selects a ciphersuite that requires no client-side authentication, when at least one resource protected by one of the protection sets is requested.

5 53. The system of claim 52 wherein the secure web server automatically selects the TLS ciphersuite TLS_RSA_WITH_AES_128_CBC_SHA.

54. The system of any one of claims 40 to 53 wherein the secure web server presents a self-signed certificate to establish the secure session.

0

55. The system of claim 54 wherein the client application authenticates the secure web server implicitly, thereby removing reliance on a trusted certificate.

13