WO2008053279A1

WO2008053279A1 - Logging on a user device to a server

Info

Publication number: WO2008053279A1
Application number: PCT/IB2006/054043
Authority: WO
Inventors: Ebbe Skak Larsen
Original assignee: Danske Bank A/S
Priority date: 2006-11-01
Filing date: 2006-11-01
Publication date: 2008-05-08

Abstract

This invention relates to a method for logging on a user device to a server comprising the following steps: receiving user authenticating credentials, e.g. a user id and/or a password, at the user device, generating an asymmetric key pair constituting a private user key and a public user key on the user device; receiving on the server a package; extracting the user id and the password from the package, and comparing the password with a password associated with the extracted user id on the server; entering the status of being pre-authenticated provided there is a match between the password and the password associated with the extracted user id; determining on the server user authenticating means; sending the user authenticating means in a SMS to an associated cell phone or user device; receiving user authenticating means or a response to the received user authenticating means; transferring an encrypted one-time password to the server, and comparing this one-time password with a an earlier generated one-time password, and entering the status of a proper two-factor authentication provided the two one-time passwords are equal.

Description

LOGGING ON A USER DEVICE TO A SERVER

The invention relates to methods and a computer program product for logging on a user device to a server, e.g. a bank server for use in a subsequent session, e.g. in a home banking session.

Systems dealing with data transfer in connection with e-banking are known. From the granted European patent EP 1 349 031 B1 a possible implementation of e- banking is disclosed. The technique in EP 1 349 031 B1 regards user and data authentication by means of a client from which the user has access by means of user-controllable card reader. A method in EP 1 349 031 B1 performs a user authentication step and a data authentication step as well. Moreover EP 1 349 031 B1 applies a secure memory, which is not removable from the card reader, the latter being applied for the user to sign in the logon process.

The technique dealing with data transfer in connection with e-banking disclosed in EP 1 349 032 B1 regards two step data authentication by means of a client from which the user has access by means of user-controllable card reader. EP 1 349 032 B1 discloses the application of two keys associated with of a user-controllable card reader and a smart card, respectively. A 1024 bit RSA key is applied as the private key of the two keys.

US patent application US 2002/0023215 discloses a method and apparatus each for approving a transaction request between an electronic transaction system and a portable electronic authorisation device. A user using an electronic authorisation token carries the portable electronic authorisation device. To enhance the security level, a private key is stored on the portable electronic authorisation device, whereas the decryption key is stored outside the portable electronic authorisation device at a trusted third party location. When the user attempts to make a signature, the software sends a request for the decryption key, along with the users password or pass phrase keyed in at the keyboard of the PDA, smartphone or cellular phone to a server belonging to the trusted third party. The server checks the password or pass phrase received and, if it is correct, sends the decryption key to the portable device, where the decryption key is used once, and thereafter immediately discarded.

US patent US 6,615,350 discusses a technique for module authentication and binding library extensions. A chain of certificates signed and verified with the use of asymmetric key pairs may be part of the initial authentication mechanism. The apparatus, system and method disclosed in US 6,615,350 each provides an initial and on-going authentication mechanism with which two executable entities unilaterally or bilaterally authenticate the identity, origin and integrity of each other. The initial authentication mechanism may include digitally signed challenge and possible encrypted response constructs, which are alternately passed between the authenticating and authenticated executable entities. Representative asymmetric key pairs include a runtime key pair, a per-instance key pair and a certifying authority master key pair.

Cryptographic Processes

Modem cryptography protects data transmitted over high-speed electronic lines or stored in computer systems. There are two principal objectives: secrecy, to prevent the unauthorised disclosure of data, and integrity (or authenticity), to prevent the unauthorised modification of data. The process of disguising plaintext data in order to hide its substance is encryption, and the encrypted result is cyphertext. The process of turning cyphertext back into plaintext is decryption.

A cryptographic algorithm, also called a cipher, is the computational function used to perform encryption and/or decryption. A cryptographic key or keys control both encryption and decryption. In modern cryptography, all of the security of cryptographic algorithms is based in the key or keys and does not primarily depend on keeping any details of the algorithm secret.

There are two general types of key-based cryptographic algorithms: symmetric and public-key. Symmetric algorithms (also called secret-key algorithms) are algorithms where the encryption key can be calculated from the decryption key and vice versa. Examples of symmetric algorithms applied in the invention are TEA, DES, 3DES, AES, Blowfish, Twofish, Yarrov etc. These require that a sender, i.e. a user device, and a receiver, e. g a server or vice versa - agree on these keys before they can protect their communications using encryption. The security of these algorithms rests in the key, and divulging the key allows anyone to encrypt and decrypt data or messages with it.

In public-key algorithms (also called asymmetric algorithms), the keys used for encryption and decryption differ from each other in such a way that at least one key is computationally infeasible to determine from the other. To ensure secrecy of data or communications, only the decryption key need be kept private, and the encryption key can thus be made public without danger of encrypted data being decipherable by anyone other than the holder of the private decryption key. Conversely, to ensure integrity of data or communications, only the encryption key need be kept private, and a holder of a publicly-exposed decryption key can be assured that any cipher- text that decrypts into meaningful plaintext using this key could only have been encrypted by the holder of the corresponding private key, thus precluding any tampering or corruption of the ciphertext after its encryption.

Most public-key cryptographic algorithms can be used to provide only one of secrecy or integrity, but not the other; some algorithms can provide either one, but not both. The RSA (Rivest, Shamir, and Adleman) public-key algorithm (U.S. Pat. No. 4,405,829), however, whose security is based on the difficulty of factoring large numbers, has been effective in providing both secrecy and integrity.

A private key and a public key may be thought of as functionally reciprocal. Thus, whatever a possessor of one key of a key pair can do, a possessor of the other key of the key pair can undo. The result is that pair-wise, secret, protected communication may be available without exchange of private keys. Thus, in general, a receiver in possession of its own private key may decrypt messages targeted to the receiver and encrypted by the sender using the receiver's public key. A receiver may authenticate a message, using its own copy of a sender's public key, to decrypt data (e.g., a signature) encrypted using a sender's private key corresponding to the sender's public key.

An asymmetric algorithm applied in the invention, e.g. RSA, DSA, ECC, etc as- sumes that the server public key is well published in an integrity and identity secure manner to the user device, e.g. typically within the actual component under a code integrity signature, typically by VehSign. The secure publishing of the user public key is important for the invention and should not be assumed, but explicitly handled. A sender (user of a public key associated with a receiver) can then know that the public key is valid, effective, and non-tampered with. One way to ensure integrity of data packets is to run data through a cryptographic algorithm. From an encryption or from a compression of data, data can somehow be retrieved again, which is not possible for cryptographic hash functions. A hash algorithm is a one-way function, which delivers a "digest" or a "footprint" of the given data of a certain static length. Such hash algorithms are commercially available. When a hash function is challenged, it means that someone has published a method to find collisions faster than using brute force. For example, the message digest 5 (MD5) and the Secure Hash Algorithm, SHA-1 are challenged, making the SHA-256 the currently preferred hash algorithm.

A certificate may be thought of as a data structure containing information or data representing information, associated with assurance of integrity and/or privacy of encrypted data. A certificate binds an identity of a holder to a public key of that holder, and may be signed by a certifying authority, CA. A signature is sometimes spoken of as binding an identity of a holder to a public key in a certificate. As a practical matter, a certificate may be very valuable in determining some level of confidence in keys associated with encryption. That is, just how "good" is an encryption in terms of privacy and integrity. That confidence level may be established by means of a certificate hierarchy. By certificate hierarchy is meant a certification process or series of processes for providing certificates from a trusted authority to another creator of keys.

A certificate, being a data structure, may e.g. contain data regarding the identity of the entity being certified as the holder of the key associated with the certificate, the key held (typically it is a public key), the identity (typically self-authenticating) of the certifying authority issuing the certificate to the holder, and a digital signature, protecting the integrity of the contents of the certificate. A digital signature may typically be based on the private key of the certifying authority issuing the certificate to the holder. Thus, any entity to which person the certificate is asserted may verify the signature corresponding to the private key of the certifying authority.

In general, a signature of a certifying authority is a digital signature. The digital sig- nature associated with a certificate enables a holder of the certificate, and one to whom the certificate is asserted as authority of the holder, to use the signature of the certifying authority to verify that the contents of the certificate have not been modified. Such verification assures the integrity and authenticity of the certificate and of the public key in the certificate. This verification is accomplished using the certifying authority's public key.

Cryptography, especially public key cryptography, provides certain benefits to software designers. These benefits are available in situations where data may be shared. Many modern software packages (applications, operating systems, execu- tables) are used in businesses or in other networks where multiple "clients" may share a network, data, applications, and the like. Most modern software packages employ cryptography in some form.

One application for cryptography in network management or network operating systems includes authentication. Also, integrity of data packets transferred, encryption of files, encoding associated with licenses for software or servers, and license distribution or serving are some of the applications for cryptography.

Users may be identified and their rights to access may be authenticated by means of passwords on a network. Cryptography is typically used to transfer some authentication, integrity, verification, or the like in a secure manner across a network that may be open to channel tapping. Public key cryptography is typically used in such a circumstance. Another application of cryptography for authentication involves a single sign-on.

This may remain true regardless of the number of servers that may eventually be called into service by the individual user (client) during this single session. Historically, scripts have been used to provide a single sign-on, but public key mechanisms are now being provided for this function.

Users have previously demonstrated that networks may be subject to attack by spoofing of network control packets. This procedure may be demonstrated in playback and in man-in-the-middle scenarios. By such spoofing, users may obtain unauthorised privileges on a network server. Adding packet signatures keyed on a per- session basis may provide improved packet integrity.

Certain licensing schemes may use various encryption modes to protect software against piracy by end users and others throughout a distribution chain. Data structures, cryptography methodologies, checks, and other protection mechanisms may be proprietary to a software developer. Nevertheless, license server mechanisms are being developed to support control of the use of application software in confor- mity with licenses. An application software provider may provide licenses. The license server may use public key cryptography to create and verify signed data structures. Secret key cryptography may be used to support authentication and file encryption.

Certain applications may provide file confidentiality using proprietary, exportable, secret key algorithms. Users in large numbers make use of such algorithms. Nevertheless, considerable interest in breaking such proprietary algorithms has been successful with certain software. Proprietary encryption methodologies have been consistently broken, given enough time and attention by interested hackers.

Certain applications use public key cryptography for digital signatures. Market leaders in software have provided relatively weak secret key algorithms adopted by others. Thus, files written in different applications from different vendors, even en- crypted files, may be opened by an application from any of the vendors using the market leader's secret key algorithm. Within a single product line, a vendor of software applications may use multiple algorithms. Several, if not a plethora of, algorithms exist, including both secret key algorithms and public key algorithms. Stream and block ciphers, as well as hash functions, are available and well documented in the computer programming art.

Dynamic Authentication of Independent, Executable Entities

Personal computers, including laptops, workstations, cellular phones, Personal Digital Assistants, i.e. PDA's, and other more powerful computers, are increasingly linked through communications networks, the span and scope of which are increasing daily. Whereas once computers were only accessed and used within the secure confines of glass-enclosed computer rooms, today they are often accessed re- motely, even from the other side of the world. Likewise, although in the past company-owned communications facilities, dedicated private networks, and/or value- added Networks provided a certain amount of control over who could connect to them, today public facilities, such as the Internet, are very widely used to provide ubiquitous interconnection.

It is an object of the invention to provide methods and a computer program product, which each enhance the security in a home banking application both when logging on the user and in the subsequent session.

Moreover, it is an object of the invention to provide mobility without sacrificing security and integrity, i.e. the user can access her e-bank from anywhere from any suitable user device.

Moreover, it is an object of the invention to provide an easy understandable logon, i.e. where the user does not have to be bothered with installing a key-file or to have any other dedicated software or a customised set up. Further, it is an object of the invention to provide that data are not left on the user device, which enables a fraudulent person, e.g. a hacker, to access the user device in place of the rightful person.

Additionally, it is an object of the invention to render so-called man-in-the-middle attacks impossible up to cryptographic strength.

Additionally, it is an object of the invention to increase the difficulty of attempting a dedicated so-called Trojan horse attack.

Additionally, it is an object of the invention to effectively limit the time windows in which the result of a possible successful Trojan horse attack may be used.

The above object, the above advantage, and the above feature together with nu- merous other objects, advantages, and features, which will be evident from the below detailed description of the present invention and are in accordance with the teaching of the present invention, are obtained by the following four aspects of the invention, where a first aspect of the present invention is a method for logging on a user device to a server, said method comprising the steps of:

interacting from the user device with said server,

receiving user authenticating credentials, e.g. a user id and/or a password, at the user device,

optionally generating a symmetric session key on the user device,

generating an asymmetric key pair constituting a private user key and a public user key on the user device,

optionally encrypting the asymmetric key pair using the symmetric session key on the user device, optionally determining a hash value of the received password on the user device,

compiling a data package comprising the received user id, either the determined hash value of the password or the password itself and optionally the symmetric session key, and signing the data package with the private user key on the user device,

adding the signature from the signing and the public user key to the data package on the user device,

encrypting the data package using the public server key to a logon package on the user device,

receiving on the server the logon package and decrypting the received logon package using the private server key,

extracting the signature from the received decrypted logon package,

verifying the extracted signature with the public user key,

extracting from the received decrypted logon package the user id and optionally the symmetric session key,

extracting from the received decrypted logon package the hash value of the password or the password itself, and comparing the password or the extracted hash value of the password with a password associated with the extracted user id on the server,

continuing executing the method and entering the status of being pre- authenticated provided there is a match between the extracted hash value of the password or the password and the password associated with the extracted user id on the server, or, if there is no such match stopping the method in an error state and entering the status of being non pre-authenticated,

determining, on the server, user authenticating means, e.g. a cell phone number associated with the user, an e-mail associated with the user, a row and column number on a matrix key cardboard associated with the user, or a one-time password,

sending the information about the user authenticating means, e.g. in a SMS and/or in a MMS message and/or in an e-mail, to a cell phone associated with the cell phone number, or to the user device,

receiving the additional credential information, e.g. the SMS and/or the MMS message and/or the e-mail with the information about the user authenticating means, on the cell phone or on the user device,

receiving the user authenticating means or a response to the received user authenticating means, e.g. as a one-time password, on the user device,

optionally either calculating a hash value of the one-time password, encrypting the hash value of the one-time password on the user device and transferring the encrypted hash value of the one-time password from the user device to the server, or transferring an encrypted one- time password to the server,

decrypting the received encrypted hash value of the one-time password or decrypting the received one-time password on the server, and comparing this one-time password with a an earlier generated one-time password on the server, and

continuing executing the method provided the two one-time passwords are equal and entering the status of a proper two-factor authentication, otherwise stopping the method in an error state and entering the status of being non-authenticated at all.

According to a second aspect of the present invention, the invention comprises a method for logging on a user device to a server, said method comprising the steps of: interacting from the user device with said server,

receiving user authenticating credentials, e.g. a user id and/or a pass- word, and a one-time password at the user device,

optionally generating a symmetric session key on the user device,

optionally encrypting the asymmetric key pair using the symmetric session key on the user device,

optionally determining a hash value of the received password and of the one-time password on the user device,

compiling a data package comprising the received user id, either the determined hash value of the password or the password itself, and ei- ther the determined hash value of the one-time password or the onetime password itself, and optionally the symmetric session key, and signing the data package with the private user key on the user device,

encrypting the data package using the public server key to a logon package on the user device, receiving on the server the logon package and decrypting the received logon package using the private server key,

extracting the signature from the received decrypted logon package,

verifying the extracted signature with the public user key,

extracting from the received decrypted logon package the hash value of the password or the password itself and the hash value of the one-time password or the one-time password itself, and comparing the password or the extracted hash value of the password and the one-time password or the extracted hash value of the one-time password with a password associated with the extracted user id on the server and a one-time password on the server, respectively, and

continuing executing the method and entering the status of being properly authenticated provided there is a match between the two set of passwords, or, if there is no such match, stopping the method in an error state and entering the status of being non-authenticated.

In a preferred embodiment of the above-mentioned methods, the private key is from an asymmetric algorithm, most preferably RSA, preferably DSA or ECC.

In a further preferred embodiment of the above-mentioned methods, the symmetric algorithm most preferably is 3DES, and preferably AES, Blowfish, or Twofish.

In an additional preferred embodiment of the above-mentioned methods, the hash function most preferably is SHA-256, and preferably an SHA-1 or MD5. In yet another preferred embodiment of the above-mentioned methods, the user device most preferably is a personal computer, and preferably a PDA or a Smart- Phone.

In accordance with a third and fourth aspect of the present invention, the methods of aspects one and two are stored on a computer readable medium having software code instructions for performing the methods.

In a preferred embodiment of the third and fourth aspect of the present invention, the computer readable medium is a USB stick, a RAM stick, a PCMCIA card, a DVD, or a CD.

By means of the computer readable medium the software can be stored on the server, read into the memory, e.g. in RAM for executing. Correspondingly, the com- puter readable medium can be sold or delivered to the user, be read from the user device, read into the memory, e.g. in RAM or the browser cache for executing.

Hereby, is possible for the software provider to provide the software on the USB or RAM stick, the PCMCIA card, the DVD, or on the CD for installation and execution on the user device and/or on the server.

Alternatively, the software methods according to the present invention is downloaded from the server to the user device and stored in the browser cache for subsequent use.

In the present context, the user uses her user device, e.g. a personal computer, a PDA or a SmartPhone to logon. Moreover, any other personal computer, PDA or a SmartPhone may be used, since it is not a prerequisite for the invention that a key- file - as known in the art for home banking - is required. Accordingly, the user can logon anywhere from her user device, which need not be set up for her, e.g. the user can borrow any user device, for example log on from a personal computer in a public library or from an Internet cafe. Accordingly, the user is not bound by the use of a dedicated personal computer or the set up of the computer and/or that the computer is to be installed with dedicated software and personal setting which is located on a specific site, e.g. in a home, but the user may use any user device as exemplified.

The invention has the following advantages:

The methods are based on the use of asymmetric key pairs with very short life spans, i.e. keys that only live for the duration of a session.

The methods apply separated authentication, and authentication methods are likely to change over time. The authentication methods may consist of several types of credentials and factors. User id with a static password is one example of the used authentication method with the addition of a one-time password.

As regards the component used, any platform applied as user device, or any operative system that supports running any type of code with crypto capabilities, are possible end-user targets - at the user side - for this method. The method can be developed in any language and should be subject to code integrity to the extent sup- ported by the target system.

Most commonly used in Web-scenarios are downloaded components, i.e. they reside on the actual (net bank) server and the browsers will detect, if the user device in question has the proper (version of) the component. If this is not the case, the component is automatically downloaded to the user device and installed to run there. Most typically a code integrity security system is used to ensure the user that the proper code is running (not e.g. a hacked code). VehSign is typically the provider and CA of such code integrity.

Currently it may be recommended using Java Applets or ActiveX components for the broadest possible coverage with MS.NET assemblies as a serious candidate now or within a few years, depending on the actual usage scenario on the intelligent chosen user device. For code integrity, the use of VeriSign is recommended, which is very widely supported in browsers and thus covers the interesting web-usage scenarios.

The server public key will be embedded within the selected code integrity ensurance scheme, in order to ensure that Alice's component (user device) may encrypt messages readable only to the bank by use of the server private key.

As regards confidentiality, the methods hold keys to ensure explicit encryption options of any type of data, which the user wishes to encrypt for delivery to the bank.

In some instances (e.g. with semi-risk around disclosure for web-based systems like net banks), one may elect to discard the usage of explicit application to application encryption and rely on other means of secrecy, e.g. link-2-link encryption using SSL or VPN. The encryption key length depends on the security level to be maintained. Normally for net banks, the recommendable link-2-link encryption method is SSL 128 bit.

As regards significant signing, the methods support digital signatures on any type of data and are recommended for use when transferring any data, where data integrity is important, e.g. when approving payments in net banks or similar.

With respect to integrated signing flow, Alice is presented with the data to be signed and the actual signing of data, using her private key, will be done within the same process, both with regards to keeping it technically in-process and with regards to Alice's working process and understanding of the concept.

This process is specific to scenarios where presentation of the data to be signed is important (which is the case for net banks). In that case things should be kept in- process for understanding and security reasons, and the presentation form may even set up requirements for the format of the data and the presentation (e.g. it could need some dialect of XML with XSL as presentation or the like). Other scenarios where the scheme may be used in a more API-like fashion (integration with ERP-systems or similar) may allow signing any type of data without an in-process presentation, i.e. it could be completely without graphical user interface.

Hidden HTML fields may be used to transfer the secured data - i.e. data from the protocols described for this method - back and forth between the bank and the client as the user device. This is merely a convenient communication choice, and the term 'hidden' means that the fields are not visible to the user, i.e. not rendered as HTML. In this sense, the term 'hidden' does not imply any security features, and the content of these hidden fields is actually readily available to the user through viewing the HTML-source, thus emphasizing the importance of securing this data further as presented in this method.

If the protocol is not HTML, but something else like TCP/IP or a proprietary protocol, hidden variables does not apply. The security data is independent of communication form and are secured pier-2-pier in their own right. Thus data may be transported through any means and choice of communication, as long as data arrives to the server.

No key files or cookies or any I/O with possible policy restriction are used. Accord- ingly, it makes no sense for a hacker to attempt obtaining these. There will only be a graphical interface with standard user input facilities, and a standard API for use by e.g. a browser scripting or other means of software integration.

Experience with other types of Java-based security components ensures that a suf- ficiently random seed for secure key generation from user interactions as well as good performance with seed collecting and key generation are possible. This also applies for ActiveX components and MS.NET assemblies. It is assumed that the availability of sufficiently random seeds is the case.

The private key resides encrypted in memory. For each use it is decrypted, at which point it is in clear text in memory. After use, the clear text key should be overwritten in memory using randomly generated content to minimise exposure windows. The effect of this may be somewhat language implementation dependent, e.g. through garbage collection in Java or similar.

As regards algorithms, the asymmetric algorithm RSA with 1024 bit keys is applied in a preferred embodiment, since it has a good back-end support.

A symmetric algorithm is applied in a preferred embodiment for session control and for data encryption, which symmetric algorithm is chosen to be 3DES with 112 bit effective key length. It is quick, secure and supported on the back end.

For the hashing, the secure hash algorithm SHA-256 is applied in a preferred embodiment.

All algorithms and key lengths may be frequently evaluated and changed within the methods.

The invention will be explained in more detail below in connection with the preferred embodiments and with reference to the drawings, in which:

fig. 1 shows the challenge/response scheme, figs. 2a, 2b and 2c in conjunction show a one-round trip logon flow, and figs. 3a, 3b, 3c, 3d and 3e in conjunction show a two-round trip logon flow.

Throughout the drawings, the same abbreviations indicate identical elements or variables. In the present specification, variables or elements identical to variables or elements, respectively, described previously with reference to a preceding figure are designated by the same text, symbol or abbreviation.

Figure 1 illustrates the challenge/response scheme. For this scheme enrolment is done when Alice establishes her method of two-factor authentication, and throughout the specification this is assumed to be done securely. Alice's public key for the session is associated with her authenticated identity (i.e. enrolled with respect to signature usage) during the logon scenario shown in the figure.

Explicit user-oriented key management is only necessary if the keys live beyond a session, which is not the case here. The asymmetric key pair in question is automatically generated at logon time and discarded at the end of the session, at which point the keys expire and will never be used (or at least accepted) again.

The keys are not stored outside memory and Alice will never have to think about them at all and thus never need to learn any type of key management in addition to keeping her authentication method safe. This means that she only has to keep her password and user id safe.

Maintaining a secure session is based on both parties (user device and server) sharing a secret key. The logon procedures (figure 2 and 3) will ensure this securely, and for this section it is simple herein assumed that both Alice and the bank are in possession of the same session key KeySym.

Figures 2a, 2b and 2c illustrate a one-round trip logon flow. The one-round trip flow is a method for logging on a user device to a server. The server may be a bank server, and the method may be applied prior to a home banking session, the method comprises the following steps:

Alice interacts from the user device with the server, and is e.g. presented with a logon screen, e.g. a homepage. It could be any valid interaction with a server, i.e. through FTP, web services, etc. Even though the Internet is shown, it does not have to be the Internet. Any type of electronic communication between parties (user device and server) can be secured in this way. The Internet is just the most commonly used (and attacked) way of connecting. It does not have to be a home-banking session. It could be any type of system that requires this level of security. In fact, the method could be used entirely without a session, i.e. in the case where one just wants to deliver some signed data once. If a "one-round trip" authentication system is used, one can actually securely deliver the signed data and enrol the keys in one single package with no need to establish a session. In this case the person does not have to establish a session key.

After the interaction with the server, some code information is set up. The code may represent a logon screen image possibly associated with a unique session id on the server in response to the access to the homepage from the user device. After being set up, the code information is transferred - possibly with the unique session id - to the user device for presentation.

In practice many sessions run simultaneously on the server, and some data - e.g. the unique session id - should be available to identify what session content belongs to whom. This can be done in many different ways, which are all independent from this invention.

The presentation is e.g. a presentation of the logon screen image on the user device. The first logon screen image contains fields into which the user Alice is prompted to enter her user credentials, e.g. her user id and password. Thus the user device receives the user id and/or the password. Moreover, as a further authentication means, Alice additionally provides a one-time password in her logon process. Alice is assumed to be already in possession of a one-time password generating device or system and able to use it.

The system/device (one-time password device) could be any one-time password generating device e.g. a device/system which is a symmetric key carrier with some simplifying functionality and means for input/output. Basically a crypto-unique symmetric key is generated and entered into both the device and the back-end server system. They may be time dependent, in which case clocks are synchronised. They may be event-dependent, in which case both event-"counters" are set to the same start value (typically zero). Symmetric crypto algorithms (typically 3DES) may now at any time calculate both the actual one-time password) (from the device) and the expected one-time password (from the server). If these two match, the user must have had access to the one-time password device and they must be "in sync" with time and event if used.

An explicit built-in logon screen is not necessary for the invention. Only the actual input is interesting (user id and password), which are really any unique identifying data for the user. These data or user credentials could easily be entered as parameters to an API with this invention implemented inside. This also applies to the one-time password, which is entered to the user device.

Typically, Alice clicks 'OK' or enters to confirm the data provided.

As an option, the user device generates a symmetric session key if a Secure ses- sion is needed, and in the Secure Session the symmetric session key is given securely to the server during the logon process and subsequently used at the user device and at the server to secure the session. It is possible to discard the Secure Session and the usage of the symmetric session key for this, since some other means, e.g. VPN, may be used.

The session key may be generated because it may be used to protect the session and the keys within the session. When this key is exchanged with the bank system, it is encrypted using the server public key, i.e. it is very strongly encrypted with the bank as the only holder of the private key, which is typically stored within HSM only.

The user device generates an asymmetric key pair. The pair constitutes a private user key and a public user key.

In this protocol - since the key pair is completely discarded after each comparatively very short session - it increases the difficulty for a hacker to pick keys out of memory, write or swap files and use them during the session. As an option, the user device encrypts the asymmetric key pair using the symmetric session key or another symmetric key generated for this purpose. This encryption could also be discarded depending on the choice of the user device security.

As a further option, the user device determines a hash value of the received password. The use of hashing or "hash values" is another typical security convention or choice.

If only the hash value of the received password is exchanged with the server, it serves the purpose of not exposing the actual password to administrators within the bank.

The task could just as easily be accomplished by just using the actual password, i.e. non-hashed. It opens some security issues when storing the corresponding pass- word centrally, but it is still a matter of security level choice, and thus just a recommendation.

Correspondingly, also as an option, the user device determines a hash value of the received one-time password. The use of hashing or "Hash values" is another typical security convention or choice. The task could just as easily be accomplished by just using the actual one-time password. It opens some security issues when storing the corresponding one-time password centrally, but it is a matter of security level choice, and thus just a recommendation. Of course, by hashing the password and/or the one-time password, it makes it difficult for a hacker to reveal or steal the pass- word and the one-time password because the hashed values does not provide this information, i.e. "de-hashing" makes no sense.

As the next step, the user device compiles a data package, e.g. by use of a tuple to hold the data. The data package comprises the just received user id, either the de- termined hash value of the password or the password itself. Further, the data package comprises either the determined hash value of the one-time password or the one-time password itself, and optionally the symmetric session key. Subsequently, the data package is signed with the private user key. Again, hashing - or not - of one and/or two of the passwords, is a choice that depends of the level of security chosen.

The user device then adds the signature from the signing with the public user key to the data package. The whole package is then encrypted using the public server key to provide a logon package, which then has been established on the user device.

The logon package is subsequently sent to the server, which in turn receives the logon package and decrypts it using the private server key. Actually, this data pack- age was encrypted on the user device using the server public key, which means that it can be decrypted only using the corresponding server private key, which is in safe possession on the server only.

By encrypting the entire logon data package using the server public key it is ensured that no one can read or make undetected changes to the data except the server, e.g. a bank, and then only after decryption using the corresponding server private key.

The server then extracts the signature from the received and just decrypted logon package, and the server verifies the extracted signature with the public user key. Subsequently, the server extracts - from the received decrypted logon package - the user id and optionally the symmetric session key, if one wants to establish a secure session. Especially saving the data within the session is independent of the invention and should simply follow the session-oriented methods provided by the used web server or other type of back-end used for running the system in question.

The server moreover extracts - from the received decrypted logon package - the hash value of the password, or the password itself, and compares the password or the extracted hash value of the password with a password associated with the ex- tracted user id.

Further, the server moreover extracts - from the received decrypted logon package - the hash value of the one-time password, or the one-time password itself, and com- pares the one-time password or the extracted hash value of the one-time password with a one-time password associated with the extracted user id. If a comparison is made with hashed value of the one-time password, the one-time password on the server side is hashed - or retrieved as hashed - prior to comparing the two hash values.

The hash value(s) of the data is extracted by decrypting by using the user public key, which is also called de-signing. Then another hash value is generated from the data, which was transferred in the logon package and claimed to be the basis for the hash value(s) generated and encrypted in the user device.

Having thus thoroughly secured and verified all parts of the logon package, the credentials, i.e. the hashed value of the password and the one-time password, are then checked against the centrally administered corresponding back ends.

The method continues and enters the status of being properly authenticated provided there is a match between the two sets of passwords, i.e. when the two onetime passwords (or their hash values) are identical and when the two passwords - or their hash values - are identical as well.

Conversely, if one of the two sets or both set of passwords did not match, the method is brought to a stop in an error state and thus enters the status of being non- authenticated at all.

The "one-round trip" method/logon flow may be extended to an "any number of- round trips" approach, e.g. to two, three, four, trips, etc.

The Figures 3a, 3b, 3c, 3d and 3e illustrate a two-round trip logon flow. The two- round trip flow is a method for logging on a user device to a server. The server may be a bank server, and the method may be applied prior to a home banking session, the method comprising the following steps: Alice interacts from the user device with the server, and is e.g. presented with a logon screen, e.g. a homepage. It could be any valid interaction with a server, i.e. through FTP, web services, etc. Even though the Internet is shown, it does not have to be the Internet. Any type of electronic communication between parties (user de- vice and server) can be secured in this way. The Internet is just the most commonly used (and attacked) way of connecting.

It doesn't have to be a home-banking session. It could be any type of system that requires this level of security.

In fact, the method could be used entirely without a session, i.e. in the case where one just wants to deliver some signed data once. If a "one-round trip" authentication system is used, one can actually securely deliver the signed data and enrol the keys in one single package with no need to establish a session. In this case, the deliver- ent does not need to establish a session key.

After the interaction with the server, some code information is set up. The code may represent a first logon screen image possibly associated with a unique session id on the server in response to the access to the homepage from the user device. After being set up, the code information is transferred - possibly with the unique session id - to the user device for presentation.

In practice, many sessions run simultaneously on the server, and some data - e.g. the unique session id - should be available to identify which session-content be- longs to whom. This can be done in many different ways, all of which are independent from this invention.

The presentation is e.g. a presentation of a first logon screen image on the user device, and the first logon screen image contains fields into which the user Alice is prompted to enter her user credentials, e.g. her user id and password. Thus the user device receives the user id and the password. An explicit built-in logon screen is not necessary for the invention. Only the actual input is interesting (user id and password), which are really any unique identifying data for the user. These data or user credentials could just as easily be entered as parameters to an API with this invention implemented inside.

Typically, Alice clicks 'OK' or enters to confirm her data.

As an option, the user device generates a symmetric session key if a Secure session is needed, and in the Secure Session the symmetric session key is given se- curely to the server during the logon process and subsequently used at the user device and at the server to secure the session. It is possible to discard the Secure Session and the usage of the symmetric session key for this, since some other means, e.g. VPN, may be used.

As an option, the user device encrypts the asymmetric key pair using the symmetric session key. This encryption could also be discarded, depending on the choice of the user-device security.

As a further option, the user device determines a hash value of the received password. The use of hashing or "Hash values" is another typical security convention or choice. The task could be just as easily accomplished by just using the actual pass- word. It opens some security issues when storing the corresponding password centrally, but it is still a matter of security level choice, and thus just a recommendation.

As the next step, the user device compiles a data package, e.g. by the use of a tuple to hold the data. The data package comprises the just received user id, either the determined hash value of the password or the password itself, and optionally the symmetric session key. Subsequently, the data package is signed with the private user key. Again hashing - or not - is a choice depending on the level of security chosen. The user device then adds the signature from the signing with the public user key to the data package. The whole package is then encrypted using the public server key to provide a logon package, which then has been established on the user device.

The logon package is then sent to the server, which in turn receives the logon package and decrypts it using the private server key. Actually, this data package was encrypted on the user device using the server public key, which means that it can be decrypted only using the corresponding server private key, which is in safe posses- sion of the server only.

The server moreover extracts - from the received decrypted logon package - the hash value of the password, or the password itself, and compares the password or the extracted hash value of the password with a password associated with the extracted user id.

The hash value of the data is extracted by decryption by using the user public key, which is also called de-signing. Then another hash value is generated from the data, which was transferred in the logon package and claimed to be the basis for the hash value generated and encrypted in the user device. If these match, two things are ensured at cryptographic strength, i.e.:

1 ) The received data match the data sent from the user device (this is also called "integrity"), and 2) The delivered user public key corresponds to the user private key used for signing (i.e. for encrypting the data hash value).

The password may be retrieved from central password storage on the server by looking up the extracted user id.

What is done - hashing or not - depends on the choice of authentication system. In general, the user id is the key to a database/table containing the hash of the passwords. The hash value of the password is used only to prevent administrators to di- rect access the actual customer passwords, and this is a commonly known convention for security reasons. Thus, also only the hashed password may be delivered from the user device (hashed already within the user device component), and these hashes of passwords can then be compared directly.

The method continues and enters the status of being pre-authenticated provided there is a match between the extracted hash value of the password or the password and the password associated with the extracted user id on the server. Conversely, i.e. if there is no such match, the method is stopped in an error state and the method enters the status of being not authenticated at all.

In case the method continues, the server determines user authenticating means, which is e.g. a cell phone number associated with the user, an e-mail associated with the user, a row and column number on a matrix key cardboard associated with the user, or a one-time password.

The cell phone number may be determined based on the password associated with the extracted user id and/or bases on the extracted user id, e.g. by looking it up in a table.

The user authenticating means is just one example. There could be any type of further authenticating. The point is to use the pre-authenticating credentials to establish who the user claims to be. When these in fact represents this user, they should be in possession of the further means of authentication, which can then be more di- rectly addressed. It may be the knowledge of the cell phone number and the sending a code in an SMS to the cell phone associated with the cell phone number. It could also be the knowledge of an email address and the doing of a similar thing. It could also be giving the user a row and column number in order to find the corre- sponding code on a matrix key cardboard card to enter into a field. It could also be to state something important about their device, e.g. "if you are who you say you are, you should now have the number 75 (say) as the first two digits in your display". If not, you should not enter the one-time password value. For a person skilled in the art, it is obvious that a lot of further ways of proving the identity are possible.

The servers then takes care of sending the information about the user authenticating means in a SMS and/or in a MMS message to the cell phone, which is associated with the cell phone number, and/or in an e-mail. Accordingly, the user receives the additional credential information, e.g. the SMS and/or the MMS message and/or the e-mail with the information about the user authenticating means, on her user device, e.g. her PC or her cell phone. The user authenticating means may be a onetime password.

The user may then be presented with a second logon screen image. However, hav- ing an explicit further built-in logon screen presented on the user device is not necessary for the invention. Only the actual input is interesting, i.e. the user authenticating means is of interest. The data could just as easily be entered as parameters to an API with this invention implemented inside. The "two-round trip" approach may be extended to an "any-number-of-round trips" approach, e.g. to three, four, trips, etc.

The user e.g. receives the row and column number information, and - based on that information - a code is obtained. Alternatively, the user receives a one-time password in e.g. a SMS.

In any case - as examples - either the code or the one-time pass word is entered to the user device, which thereby receives the user authenticating means (one-time password) or the response (the code obtained from the row and column number in- formation) to the received user authenticating means. In practice, Alice keys the user authenticating means in, or - as a response to the received the user authenticating means - keys in a one-time password on her user device, e.g. the one-time password which is retrieved, i.e. which is determined as the corresponding code on the matrix key cardboard from the received row and column number, which code is subsequently entered into a field on the further logon screen picture, i.e. into a field on the second logon screen image.

The user device may calculate a hash value of the one-time password and may then encrypt the hash value of the one-time password, and may then transfer the encrypted hash value of the one-time password from the user device to the server. Alternatively, the user device simply encrypts the one-time password and transfers it to the server. The choice of hashing or not of the one-time password depends on the security level desired.

The server may decrypt the received encrypted hash value of the one-time password. Alternatively the server decrypts the received one-time password and compares the one-time password - hashed or not - with an earlier generated - hashed or not - one-time password on the server.

The method continues provided that the two one-time passwords - hashed or not - are equal, and in this case enters the status of a proper two-factor authentication. Conversely - in case there is no equality between the two one-time passwords - the method stops in an error state and enters the status of being non-authenticated at all.

Referring to all the figures below, all flows have been structured so as to on one or the other side describe the secure and correct configuration/structure of a data packages intended for transfer between the entities, i.e. between the user device and server. It is therefore implicit that it is exactly this data packet that is transferred as indicated by the means of the arrows. Admittedly, other elements may be transferred as indicated by means of these arrows, depending on the practical structure (it can be HTML posts/gets in WWW framework, XML in web services framework, proprietary data in e.g. IBM MQ Series or Microsoft Message Queuing typically from Clients, etc.). The actual data can be navigation in a net bank or transfer of payment files or e.g. exchange of a (costly) Krak's directory or anything else.

The security bearing elements can be transferred in hidden HTML variables or dedicated XML fields. Some times they have to be subject to further processing (e.g. base 64 expansion for transferring binary data in text protocols as HTML and XML, etc. The key point is only that these data are transferred as they are logically structured in terms of security. They are independent from any form of further protection and thus independent from their route of transport, as long as it is electronically in one way or the other.

Through out the specification of the present invention the server public key and bank public key are to be understood as synonyms. Likewise, the terms server private key and bank private key are synonyms.

This two-round trip method is almost identical to the one-round trip method until step 6. However, the authentication accomplished from step 1 through 6 is only a one- factor authentication (even though these credentials are very tightly protected within the shown protocol) and are used merely as a good assumption, i.e. "assuming you really are Alice, you should be in possession of the next means of authentication to make this a two-factor identification", in this case the cell phone with the registered phone number.

Having securely exchanged the strong symmetric key, this will be used to finish the two-factor protocol securely, i.e. the hash of the one-time password will under this security ensure that the holder of the exchanged keys also has access to Alice's cell phone. Under reasonable two-factor assumptions, this infers that the holder of the keys is in fact Alice! If the secure session and symmetric session key was optionally discarded, then the latter exchange of information to finish the two-factor protocol should be secured using the established User key pair, i.e. signing the information using the User private keys and then encrypting the result using the server public key.

When using the private user key to generate digital signatures, Alice will look through the data and press 'OK', making the component decrypt the private user key automatically, and sign.

The perceived security - and to some extent the actual security as well - could be improved by using the hash of Alice's password concatenated with the symmetric session key to encrypt the asymmetric key pair in memory. This would mean for Alice that she would have to enter her password for each digital signature, making her feel more secure but also introducing a less user-friendly scenario.

For a hacker it would introduce one more step and need of knowledge to get to the private user key. In theory it would not mean very much, as the hacker would still need access to Alice's user device in order to perform the attack and thus have the opportunity to keyboard sniff the password.

The scenario where Alice leaves her user device, e.g. PC, open and unattended for a while would be addressed more securely with a session password, and it would also be harder for Alice to argument that she accidentally entered into an agreement with digital signature by pressing 'OK' instead of 'Cancel' on the digital signature screen.

Even if the password is discarded from the choice of a PIN-coded one-time password token, one may still elect to let Alice enter an additional password, which is then completely local and session-based. This may increase at least the perceived security.

Instead of merely authenticating Alice and thus binding the session-based public user key to her credentials, it would be possible to add a secure protocol that ex- changes a CA-certified X.509 certificate with her on the fly. With that Alice could generate fully PKI compliant digital signatures on any document within the session.

It would also be possible to create a new class of certificates that only live for a day and to get these certificates stored within industry standard certificate stores like Microsoft Certificate store or similar. That would make it possible to use the server, e.g. bank systems and CA-interaction, to easily create the technical means (for nontechnical users) to set up Secure E- mail through standard clients like Outlook, or 2- way SSL tunnelling through standard clients like Microsoft Internet Explorer, while still having a relatively short time window of hacking opportunity attached to it even on an insecure platform as a PC user device. Ultimately, it would be possible to let the user decide for herself how long that window (time frame) should be exactly.

Increased Integrity

If the approach of letting the component (user device) automatically decrypt the private user key is selected, it would be possible - especially if the server, e.g. home bank, has some support for packaging the actual dynamic data content well - to digitally sign and thereby ensure integrity on all communication between Alice and the server, e.g. bank systems.

Increased Confidentiality

It would be possible with the same home bank approach to encrypt all data using the server public key (on some one-time generated symmetric key for performing the actual encryption, typically a 3DES key).

This is independent of the password choice used and is also typically available for all public key-based approaches. It is also possible to encrypt the other way, i.e. from the server to the user device using the public user key. This, however is not independent of the password choice, since Alice would not want to enter the password for each round-trip.

Digital Signature

All the necessary and usual means of creating digital signatures in a standard way, i.e. by hashing the viewed data and encrypting the hash using Alice's private user key, resides within the session memory.

When obtaining an actual digital signature on some data, a number of things should be considered:

• Data should be presented largely unchanged to the user, while still being readable

• If a display template is used, it should be bank-signed to ensure untampered display

• Data display to the user and corresponding signature from the user should be interlocked in-process to lower the probability of injecting malicious data be- tween viewing and signing

• If printed, it should be possible by hashing to verify weeks later that data to be signed is still the same as the printed data

It is sufficient to say that digital signatures are fully possibly in the methods using data from the established secure session store only.

Logoff

Logging off a home bank can be an explicit action or performed implicitly, e.g. by closing the browser. With an explicit action, it is possible to clean up the session stores immediately, i.e. discard all local information including keys from the memory. Also the bank system session store is removed and other types of cleanup are performed.

With an implicit close (i.e. the user exits the home bank by other means than explicitly logging off) there will be a short time-out period on the bank systems, after which the same clean-up procedure will be performed within the bank systems.

Locally, however, one might experience implicit logoff, e.g. through a possibly pro- voked crash of the browser on the user device, making it hard to ensure local memory cleanup.

In this case, though, there will be a time-out period during which the hacker would need to obtain the session store, extract and decrypt the private user key, re-estab- lish the session credibly with the bank, browse to the desired location within the home bank, and abuse the private user key for whatever purpose. After the time-out period, all information stored locally on e.g. the user device, will be invalid and rejected if presented to the bank systems.

Threat Scenarios

There are 5 areas in which a hacker can launch attacks, i.e. on

1. Alice herself - known as social engineering, "phishing" 2. Alice's user device, e.g. PC - known as Trojans, backdoors

3. The communication and protocols - also known as a middle-man (MITM) attack, which can be launched on the PC and bank systems as well as on the internet between these two (the traditional perception of a MITM-attack)

4. The bank systems/platforms or server(s) 5. Administrators within the bank systems These areas are treated separately in the following paragraphs below. Even though some conceivable attacks may target elements of more than one area, the methods of the present invention will still provide proper coverage if these attacks are viewed in the parts targeting each area.

Threats related to Alice's user role

Users are generally nice and helpful people. If social engineering (or phishing for that matter) is done properly, many users will - based on statistics - disclose a number of details about the security systems known to them, including passwords, user ids and PIN-codes.

In the methods according to the present invention, Alice is unable to give away any of the keys in question, since she would not know how, or probably even realise they exist, and she does not enter anything regarding the security of the methods into fields anywhere.

Threats related to Alice's user device, e.g. PC

General Considerations

Alice's PC is not a safe platform due to the lack of system surveillance and proper administration, which is what actually spawns the entire idea behind trying to supplement a public key scheme with two-factor authentication or vice versa.

As the platform is not safe, neither can any security system running on it, or in connection with it, be entirely safe. The best that can be done is basically to raise the level of skills and effort needed to attack it successfully to a sufficiently high level, and it is equally important to limit the actual business risks involved, should an attack succeed even against this raised level. If a hacker has the ability to gain total control over Alice's PC and also possesses the sophisticated knowledge, technical capability as well as the interest, time and money to simulate a component, perhaps through backward engineering of the original component, and is further able to insert and make the home bank using his own component - all without Alice suspecting anything or being able to spot the activities involved - it is possible to hack any security system on Alice's PC, including having Alice's Smart Card generate signatures on the hacker's data using Alice's pin or using Alice's one-time password entries to use the keys within a central signature server or just to deliver any transaction to the bank, while displaying whatever else to Alice making her enter the necessary input.

The threats to Alice's PC are actually all threats to Alice's key store or to the use of Alice's key.

1. Attacking the key store basically means trying to obtain the key for independent use by the hacker without having to cryptoanalyse for it. 2. Attacking the use of Alice's key means that, even though it may not be possible to use Alice's key without some human interaction originating from Alice (for example entering an one-time password coming from a device in Alice's possession, perhaps even requiring a PIN-code from Alice's memory), the attacker would insert some code that would make Alice think she is using her input correctly doing what she wants, while the hacker programs perform background operations using Alice's input on the hacker data

With regard to the existing security systems, it cannot easily be determined which security system is better, i.e. requires more work to attack. The key factor in such decision is however to note that the first form of attack can typically be done without having to simulate graphics to fool Alice, with very low penalty during Alice's interaction with her PC, and with most of the work done stealthily and inconspicuously during idle time on Alice PC or even on data transferred to hacker computers, while the second form of attack requires much more programming work, timing and intelligence to interact with Alice sufficiently well to fool her. It follows that, if the first attack scenario is possible, it could be targeted for broad attacks of 'statistical' nature, where the object is to do less work per PC and accept a high failure rate for the attack, but to spread it over thousands of PC's and perhaps even across a number of similar security systems for different home banks, and to perform the attacks using existing hacker tools already out there for almost anybody's use.

If only the second attack scenario is possible or feasible, any attack on it would have to be dedicated and even rather difficult to perform, which would put the security of the system in a key store attack area comparable to that of Smart cards and Central Signature Servers.

Security of these Methods

While the methods of the present invention enjoy the practical benefit of being inde- pendent from any kind of I/O, either to a file, Smart Card or USB device or through the internet to a server somewhere, it follows that the private user key would necessarily be present in clear text in memory for at least a brief period of time, during which it will be exposed to copying, provided it can be located quickly enough in memory by the hacker program.

For the entire session - except when the actual signing takes place - the private user key is encrypted using the session key. While it is advantageous not to expose the private user key unnecessarily long, the session key must be invoked once per round trip without user intervention, implying that at least this key must stay in clear text in memory for the duration of the session. The encryption of the private user key can thus only provide a somewhat difficult security-by-obscurity step to the skilled and knowledgeable hacker.

This is, however, standard within the traditional models, and in general it is not the actions in memory that causes concern, rather what is stored in files. It is easier to work with files, swap-files, cache, cookies and other places, where data persist for longer periods of idle time. The fact that no key file exists, and that at least the private user key is very unlikely to exist in e.g. a swap file, increases the security of the methods of the present invention well above the traditional models.

While it is actually, through some quite difficult steps, possible to obtain the private user key from memory without cryptoanalyzing for it (like threat 1 in the above paragraph), it is bound to the session and must be used within the time span of the session to have any effect. This leads to a similar scenario as with threat 2 in the above paragraph, where the most significant difference in relation to threat 1 is that there would be a little less amount of code required to actually interact with and fool Alice. This type of code, however, is not the most complex code to write and would not require the same set of skills. It would be more in the area of a 'phishing' complexity.

For most practical purposes - and certainly for general home bank use - the security on the PC for the methods of the present invention is comparable to that of Smart cards within the time span of the private key lifetime, i.e. the session.

Outside the session, however, the Smart card will still be exposed to advanced ways of attack that may prove successful in obtaining an active private key, while the keys in the methods of the present invention disappear when the session disappears and are thus completely secure with regard to Alice's PC.

Threats related to Protocols

Protocol or Man-ln-The-Middle attacks target the communication between security entities (components and systems) without having access to the entities themselves, i.e. to keys or files or memory parts and the like.

There are various levels and types of attacks, i.e.:

1. Blocking or random distortion of traffic

2. Reading traffic 3. Replaying all or parts of the traffic

4. Changing or inserting data into parts of the traffic

5. Taking over traffic control entirely

In general it is assumed that all traffic between the bank and Alice runs through an SSL tunnel, which to some extent provides protection and confidentiality to the session.

If this traffic passes through a server on the Internet belonging to a hacker, it will al- ways be possible to block traffic or change traffic into something that cannot be decrypted on the receiving end. This type of attack cannot be explicitly dealt with by other means than through detection and possibly by traffic diversion away from suspected servers. It is not a subject for further discussion in this specification, where it is sufficient to state that, while such an attack can certainly disturb Alice as well as the bank, it cannot compromise this security system.

With some non-negligible effort, it is possible to insert the hacker server as an SSL terminator for Alice and propagate traffic through another SSL tunnel to the bank. With a one-way SSL session the bank will not be able to determine identity other than through the traffic being propagated, and will thus believe that Alice is (alone) on the other end.

Alice would typically have some possible means of determining the (false) identity of the MITM-server, but it may be tampered with through browser weaknesses, or she may simple not notice that anything is wrong.

With such an MITM-attack established, the hacker would be able to read all traffic between Alice and the bank systems and indeed decide whether to perform one of the more sophisticated attacks numbered from 3 to 5.

Reading traffic is one thing, as one would simply have to determine whether or not some of the business data going through the system are important/secret enough to justify using time and CPU-power for extra encryption of data through the tunnel. The means to do so are however available (see below).

Going through the details of the three other attack types in the following paragraphs of this specification, it is hereby assumed that the described MITM-attack on SSL is already established.

Replay

Ordinarily for public key-based schemes or methods of this sort, a database with all signed transactions for all users has to be maintained for the life-span of each key pair, which obviously leads to huge amounts of data on an active site with many users and transactions.

The methods of the present invention can address replay much more efficiently, following a few very simple measures and rules.

Replay need only be considered for security-bearing data transfers, i.e. for the data transfers during logon and for digital signatures. Replay on logoff, or any other navi- gational round trip data, will be either without any real effect or stopped when the secure session gets a response mismatch, since the response from the last round trip does not match the encrypted challenge for this one.

It is of course important to distinguish between replaying an entire package or merely replaying elements from hidden HTML fields within the next package. Secure session controls will catch all replays of entire packages by nature, so the two following paragraphs of this specification will concentrate on the element of replaying.

Logon

The first logon package from Alice can be subject to replay either within this session or in a new one. If done within the same session, the system will detect a wrongful input to its very simple 'state machine', i.e. a logon request will not be accepted when in the state 'Pre-authenticated'.

However, if an entirely new session is established and the logon package from the previous one is replayed, the system will act as if Alice is trying to logon, thus playacting as if the hacker has Alice's password, i.e. one of the two factors of security in the authentication system. In other words, a replay like this would get as far as to put the bank systems in 'Pre-authenticated' mode. However, since the hacker does not have the next one-time password, either from a device or an SMS, the full replay attempt is thwarted by way of one-time password authentication. In the protocol example above Alice would even get an SMS out of the blue, indicating foul play to a certain extent.

The second logon package - if replayed within the same session - will also be caught in the 'state machine'.

If replayed within the new session - after the first 'pre-authentication' replay is done - the attempt will be rejected since the one-time password will not match the freshly generated one-time password in the server, e.g. bank systems.

The logon session protocol thus protects itself effectively against all replay scenarios without any further security measures needed.

Digital Signatures

Digital signatures are however only based on the private user key and a basic 'one- hit' protocol, where one-time passwords and secure session control do not protect against replay, i.e. without further protection, the same signed document could be delivered several times during a session.

For protection against this, it will be necessary to maintain a list of hash values from all digital signatures within the session store, and for each new digital signature de- livered through the home bank the hash value of this signature should be checked against the list, where a match would represent a replay attempt and be rejected.

When the session terminates, all this information may be discarded, since the set up of any new session will lead through the replay protected logon scenario and thereby also set up the public key K_PUB, which is for all practical purposes - following the nature of cryptographically secure randomly generated keys - different from all previous keys, making all replays outside the same session immediately rejectable.

With this, it follows that no replay database needs to be maintained, as the protocol - with only the addendum of a small session-temporary hash list - protects fully against replay.

Data Insertion

Inserting or changing data within the business application structure may cause all sorts of different behaviour, but this subject is outside the scope of this specification and the present invention, being entirely in the hands of business programmers, who would in turn be guided by secure coding principles, etc.

In this specification, focus is directed on data changes and insertions on security- bearing items only, which, of course, include digital signatures, giving programmers the opportunity to select data to be protected against data insertion or changes.

Logon items are all encrypted using keys in the memory of Alice's PC and thus out of reach for the MITM attacker. Accordingly, simply changing these item, would cause decryption to fail, which would be annoying, but not compromising to the system. As the hacker does not have Alice's session key or the server private key - and he certainly does not want to brute-force or cryptoanalyze these keys for this session only - he cannot decrypt, change stuff and re-encrypt. Thus the most intelligent attack would be to exchange entire logon items with ones created entirely by the hacker. With the first logon he would be able to present his own keys with Alice's user id, but he would be lacking the password.

Even if he could get the password through social engineering or phishing or key logging through a Trojan, he would still need the one-time password to insert with the next logon item.

Thus it is the strength of the chosen two-factor authentication methods of the pres- ent invention that determines whether or not the hacker would be able to succeed with this type of attack.

Digital signatures are the only other factor of interest for this attack type, and they are designed to effectively detect changes to data. The only option here would again be to exchange one digital signature with another one created by the hacker.

However, the hacker would have to generate and use his own key pair, and since Alice's public user key is securely bound to this session, it would be immediately evident from comparing public keys while checking the signature that the data was replaced.

Thus it is not possible within the methods of the present invention to perform undetected data insertions or changes. Again, care should be taken when choosing authentication method to use with this scheme or methods.

Session Take-over

Since the hacker is not in possession of the session key, he will not be able to produce the proper response to the bank challenge, which means that any take-over attempt will be detected upon next round trip and blocked. Threats related to the Bank Systems

There will be several different types of threats to the bank systems, including buffer overflow attacks, denial of service attacks, SQL injection attacks, etc. All of these attack types should obviously be handled, but as in the case of home bank business data, it falls outside of the scope of the methods according to the present invention and is typically in the hands of programmers, network experts, platform surveillance specialists, auditors, evaluators and the like.

Data with digital signatures should be kept safely within protected databases, but this also falls outside the scope of the methods according to the present invention. In fact, this specification assumes a safe system on the bank side if the crypto operations, session memory control, and general step given in this specification are maintained properly.

Threats from the Bank Administrator role

Administrators with evil intent could arguably insert malicious code, change database contents, read out the server private key, etc.

However, these threats are dealt with very carefully by controlling access thoroughly, requiring two or more persons to perform the most delicate operations, which banks and large installations are capable of in contrast to Alice, and which are even enforced through laws and government restrictions.

Claims

1. A method for logging on a user device to a server, said method comprising the steps of:

interacting from the user device with said server,

optionally generating a symmetric session key on the user device,

optionally determining a hash value of the received password on the user device,

extracting the signature from the received decrypted logon package,

verifying the extracted signature with the public user key,

sending the information about the user authenticating means, e.g. in a SMS and/or in a MMS message and/or in an e-mail, to a cell phone as- sociated with the cell phone number, or to the user device, receiving the information, e.g. the SMS and/or the MMS message and/or the e-mail with the information about the user authenticating means, on the cell phone, or on the user device,

optionally either calculating a hash value of the one-time password, en- crypting the hash value of the one-time password on the user device and transferring the encrypted hash value of the one-time password from the user device to the server, or transferring an encrypted onetime password to the server,

2. The method according to claim 1 , wherein said private key is from an asymmetric algorithm, most preferably RSA, preferably DSA or ECC.

3. The method according to claim 2 or 3, wherein the symmetric algorithm most preferably is 3DES, and preferably AES, Blowfish or Twofish.

4. The method according to claim 1 to 3, wherein said hash function most preferably is SHA-256, and preferably a SHA-1 or MD5.

5. The method according to claim 1 to 4, wherein said user device most preferably is a personal computer, and preferably a PDA or a SmartPhone.

6. A method for logging on a user device to a server, said method comprising the steps of: interacting from the user device with said server,

receiving user authenticating credentials, e.g. a user id and/or a password, and a one-time password at the user device,

optionally generating a symmetric session key on the user device,

compiling a data package comprising the received user id, either the determined hash value of the password or the password itself, and either the determined hash value of the one-time password or the one- time password itself, and optionally the symmetric session key, and signing the data package with the private user key on the user device,

extracting the signature from the received decrypted logon package,

verifying the extracted signature with the public user key,

continuing executing the method and entering the status of being prop- erly authenticated provided there is a match between the two set of passwords, or, if there is no such match, stopping the method in an error state and entering the status of being non-authenticated.

7. The method according to claim 6, wherein said private key is from an asymmetric algorithm, most preferably RSA, and preferably DSA, or ECC.

8. The method according to claim 6 or 7, wherein the symmetric algorithm most preferably is 3DES, and preferably AES, Blowfish or Twofish.

9. The method according to claim 6 to 8, wherein said hash function most preferably is SHA-256, and preferably a SHA-1 or MD5.

10. The method according to claim 6 to 9, wherein said user device most preferably is a personal computer, and preferably a PDA or a SmartPhone.

11. A computer program product stored on a computer readable medium having on said medium software code instructions for performing the method according to claims 1 to 5.

12. The computer readable medium according to claim 11 is a USB stick, a RAM stick, a PCMCIA card, a DVD, or a CD.

13. A computer program product stored on a computer readable medium having on said medium software code instructions for performing the method according to claims 6 to 10.

14. The computer readable medium according to claim 13 is a USB stick, a RAM stick, a PCMCIA card, a DVD, or a CD.