Abstract:
The invention relates to a personal token ( 10 ) for authentication in a network comprising a piece of software for initiating an SSL connection by generating a message authenticating said token to a remote server ( 30 ) characterized in that the piece of software controls the processing of the message so as to use of a data ( 12 ) which is prestored in the token ( 10 ) and which is specifically associated with the remote server ( 30 ) so that the message can be interpreted only by the specific remote server ( 30 ).

Description:
BACKGROUND OF THE INVENTION 
     1. Field of the Invention 
     The invention relates to security on public networks such as the Internet and more generally on any network when using personal tokens such as smart cards for authentication of users. 
     Many protocols have been proposed for authenticating a user holding a smart card in a network. 
     2. Description of the Related Art 
     Current SSL (Secure Sockets Layer) strong authentication is based on smartcard and certificates and is routinely used for authentication, without need for contacting a certificate authority that signed the certificate of the smart card. 
     One problem however arises in such scheme because of such unneeded contact with a certificate authority. 
     Indeed the smart card issuer appears to be never asked for consent before a service provider performs authentication of the smart card. In other words, the authentication process by way of a smart card is a benefit to any service provider, including any service provider who has no commercial agreement with the smart card issuer. A smart card therefore becomes a commonly benefiting authenticating tool for any entity, including competitors of the smart card issuer. 
     It is the case with standard SSL using Public Key Infrastructure (PKI) cryptography. Any server can request the client to authenticate itself using smart card PKI, while the smart card contains a private key and the associated certificate and any server can receive the user certificate and thereby check the validity of the user signature. 
     SUMMARY OF THE INVENTION 
     An aim of the invention is to allow smart card issuers to control each authentication made on their smart cards, while still relying on the standard SSL arrangements which are currently available in software and hardware on most servers. 
     This aim is achieved by way of a personal token, typically a smart card, as recited in the appended claims. An assembly comprising such token and an authentication method are also recited in the claims which both target the same principal aim. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       Other advantages, aims and features related to the invention will be discussed throughout the following detailed description, which is made with referenced to the appended figures, among which: 
         FIG. 1  depicts an architecture of an authenticating arrangement according to the invention, 
         FIG. 2  depicts an authentication process according to the invention. 
       In the following example, a remote SSL server will be called IDP, thereby referring to IDentity Provider. 
     
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
     This example relates to a SSL link which is used in order to authenticate a user using a smart card  10  on the internet via his PC (personal computer)  20 . Any other kind of personal token, also called portable token, may replace such a smart card, like a USB token or a mass memory token including authenticating data. 
     Authentication with the smart card as an SSL client is performed as follows. 
     The PC of an end user typically embeds a web browser  21  which is triggered for accessing a remotely based web site via an IT server  40 . A browser embedded in the smart card can equally be used for accessing the web site. 
     Such web site typically requires a login and the user or the smart card  10  typically selects the login link. 
     The PC  20  is presently equipped with a proxy  22  which is dedicated to IDP servers. Such proxy  22  is hereby called an IDP proxy. 
     In the present example, the client side SSL connection is not performed by the PC browser  21 , but by the IDP proxy  22  using its own built-in but standard SSL layer. 
     By selecting the login link, the PC  20  and its browser  21  are therefore redirected to the IDP proxy  22  on the client PC. 
     Then the IDP proxy  22  opens an SSL connection with the IDP server  30 . This SSL connection is secured by the card  10 . 
     The SSL connection uses a card certificate  11 . The SSL connection is successful if the card certificate  11  is a valid dongle certificate and is not in the Certificate Revocation List. 
     The IDP proxy  22  has a built-in implementation of SSL which is preferably independent from the known protocols MS-CAPI and PKCS#11. These known protocols use to pick the authenticating certificate  11  up from the card  10  and store it in the memory of the PC  20 . The same remark can be done with the SSL built-in client of Internet Explorer or Netscape which uses to offer a strong authentication using the card certificate  11  as transferred into the PC  20 . 
     By using such a different protocol, this prevents from storing the certificate in a registry or a file which is outside from the card  10 , and a third-party thereby cannot perform strong authentication using the card through preliminary transfer of the certificate into the PC  20 . 
     If the SSL connection is successful, the IDP server  30  looks-up the identity of the end-user from a dongle ID which is contained in the certificate  11 , and the IDP server  30  then returns a SAML token to the IDP proxy  22 . 
     The IDP proxy  22  then redirects the browser  21  to the service provider site with the SAML token. 
     From then on the browser  21  can access the protected site with the returned SAML token. 
     Before the SSL connection is rendered successful, an SSL authentication of the client is carried out as explained hereafter. 
     Thanks to the following arrangements, such SSL connection can exclusively be negotiated with the particular IDP server  30 . 
     This exclusivity is ensured by using the public key of the IDP server  30  which has been stored in the card  10  at a previous step, for example at the personalization step of the smart card, during the manufacturing process, or even by Over-The-Air updating of the card memory. The server public key is presently stored in the server certificate  12  which is stored in the card in the same way as the card certificate  11 . 
     As will be explained hereafter, storing the public key of the IDP server or any other server-specific information in the card  10  allows to prevent that any third-party servers may initiate a non agreed SSL connection with the smart card. 
     At the stage where an SSL connection is to be initiated between the IDP proxy  22  and IDP server  30 , an SSL handshake occurs, during which the server certificate  12  from a server-hello message is used to check the server signature. This pertains to the standard SSL implementation. 
     To enforce server verification, the card  10  contains the server certificate  12  as a fingerprint or reliable authenticator element and the IDP Proxy requests the card to check the server certificate on the basis of the stored fingerprint  12 . 
     Once the identity of the IDP server  30  is checked in the card  10 , a ClientKeyExchange message is generated in the card. 
     As a preferred example, the IDP public key of the IDP server is stored in the card  10  and is used to generate the ClientKeyExchange message. 
     To this end, the card  10  completes a usual hash processing of the data with a signature process of the data on the basis of IDP dependant data, i.e. the public key of the server  30  in the present example. 
     A strong authentication specifically dedicated to the given IDP server  30  is thereby ensured by previous storage of the public key of the server in the card, and by performing the final phase of the SSL hash cryptography in the card with the prestored public key of the IDP server. 
     Such final phase which consists in performing a server specific signature is however preferably done before performing client signature (CertificateVerify message). 
     The signature of the ClientKeyExchange message with IDP dependent data provides two main advantages. 
     The SSL connection can only be rendered successful with the specific IDP server  30  which also contains such IDP server dependent data, as far as those data are necessary in the server  30  for interpreting the content of the ClientKeyExchange message. 
     The public key of the card can therefore not be used for any other purpose than performing an SSL connection with the specific IDP server. 
     When performing signature of the message, the card  10  implements a part of the SSL protocol dedicated to the wanted IDP server and related to server public key. It means that the card signature will be valid for the wanted server  30  but not for other servers that do not own the correct server private key. Such card  10  can therefore not be used in an unauthorized environment. 
     Alternatively, the used IDP dependent data may constitute either part of the message or an encrypting tool of the message which it is necessary to know for interpreting the message. 
     The public key of the server  30  is preferably the unique key that will transport SSL key materials to the server  30 . 
     Practically, the IDP server upon reception of the card certificate  12  during the SSL connection verifies the validity of the certificate in the CRL (Certificate Revocation List), and performs an identity lookup from the card id contained in such certificate  12 . 
     If the certificate  12  is valid, the SSL connection can be used to send back a SAML token to the IDP proxy as explained before and then the IDP proxy is redirecting the browser  21  to a service provider site, thereby inviting the PC browser  21  to connect to the service provider  40  with the SAML token. 
     The site of the service provider is asserting the validity of the SAML token with the IDP server  30  and if successful, the service provider is initiating an SSL connection without client certificate with the browser of the PC. 
     The service provider  40  can be hosted in the same IDP server  30  which was connected to the proxy  21  or can be hosted in another remote server. 
     Although the strong authentication can only be performed with the allowed SSL server, the authentication remains mainly a standard SSL authentication. 
     The server public key is preferably the key which is stored in the card  10 , and not a key which may be transmitted by the server  30  during the SSL server-hello message, i.e. before initiation of the authentication process. This prevents third-party servers to initiate an SSL connection with the IDP proxy and to perform a strong authentication using the card. 
     Furthermore, due to the fact that in this particular example a standard SSL protocol is used which requires no heavy server-side custom of software or hardware, the SSL client implements the standard SSL protocol with client and server certificates, and is mainly supported on the shelf by most server software and hardware components. 
     The description has been made with reference to a smart card. However the invention relates also to other type of portable tokens for personal authentication, such a USB sticks or mass memory cards.