WO2008053279A1 - Ouvrir une session sur un dispositif utilisateur vers un serveur - Google Patents

Ouvrir une session sur un dispositif utilisateur vers un serveur Download PDF

Info

Publication number
WO2008053279A1
WO2008053279A1 PCT/IB2006/054043 IB2006054043W WO2008053279A1 WO 2008053279 A1 WO2008053279 A1 WO 2008053279A1 IB 2006054043 W IB2006054043 W IB 2006054043W WO 2008053279 A1 WO2008053279 A1 WO 2008053279A1
Authority
WO
WIPO (PCT)
Prior art keywords
user
password
key
server
user device
Prior art date
Application number
PCT/IB2006/054043
Other languages
English (en)
Inventor
Ebbe Skak Larsen
Original Assignee
Danske Bank A/S
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Danske Bank A/S filed Critical Danske Bank A/S
Priority to PCT/IB2006/054043 priority Critical patent/WO2008053279A1/fr
Publication of WO2008053279A1 publication Critical patent/WO2008053279A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/34—User authentication involving the use of external additional devices, e.g. dongles or smart cards
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/33—User authentication using certificates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/325—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wireless networks
    • G06Q20/3255—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wireless networks using mobile network messaging services for payment, e.g. SMS
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3823—Payment protocols; Details thereof insuring higher security of transaction combining multiple encryption tools for a transaction
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/385—Payment protocols; Details thereof using an alias or single-use codes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4012—Verifying personal identification numbers [PIN]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/42—Confirmation, e.g. check or permission by the legal debtor of payment
    • G06Q20/425—Confirmation, e.g. check or permission by the legal debtor of payment using two different networks, one for transaction and one for security confirmation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
    • H04L63/0838—Network architectures or network communication protocols for network security for authentication of entities using passwords using one-time-passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/18—Network architectures or network communication protocols for network security using different networks or channels, e.g. using out of band channels
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2103—Challenge-response
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/082—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying multi-factor authentication

Definitions

  • 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.
  • a server e.g. a bank server for use in a subsequent session, e.g. in a home banking session.
  • EP 1 349 031 B1 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • secrecy to prevent the unauthorised disclosure of data
  • integrity or authenticity
  • 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.
  • Symmetric algorithms also called secret-key algorithms
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • a hash function is challenged, it means that someone has published a method to find collisions faster than using brute force.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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:
  • user authenticating credentials e.g. a user id and/or a password
  • 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
  • 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,
  • 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,
  • user authenticating credentials e.g. a user id and/or a pass- word, and a one-time password at the user device
  • the private key is from an asymmetric algorithm, most preferably RSA, preferably DSA or ECC.
  • the symmetric algorithm most preferably is 3DES, and preferably AES, Blowfish, or Twofish.
  • the hash function most preferably is SHA-256, and preferably an SHA-1 or MD5.
  • the user device most preferably is a personal computer, and preferably a PDA or a Smart- Phone.
  • the methods of aspects one and two are stored on a computer readable medium having software code instructions for performing the methods.
  • the computer readable medium is a USB stick, a RAM stick, a PCMCIA card, a DVD, or a CD.
  • the software can be stored on the server, read into the memory, e.g. in RAM for executing.
  • 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.
  • 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.
  • 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.
  • the user uses her user device, e.g. a personal computer, a PDA or a SmartPhone to logon.
  • her user device e.g. a personal computer, a PDA or a SmartPhone to logon.
  • 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.
  • 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.
  • 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 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the secure hash algorithm SHA-256 is applied in a preferred embodiment.
  • fig. 1 shows the challenge/response scheme
  • figs. 2a, 2b and 2c in conjunction show a one-round trip logon flow
  • figs. 3a, 3b, 3c, 3d and 3e in conjunction show a two-round trip logon flow.
  • Figure 1 illustrates the challenge/response scheme.
  • 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.
  • FIGS. 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.
  • 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.
  • the code information is transferred - possibly with the unique session id - to the user device for presentation.
  • 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.
  • her user credentials e.g. her user id and password.
  • 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 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.
  • 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
  • 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.
  • 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.
  • 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.
  • 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.
  • the user device determines a hash value of the received password.
  • hashing or "hash values" is another typical security convention or choice.
  • 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.
  • the user device determines a hash value of the received one-time password.
  • 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.
  • hashing 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.
  • 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.
  • 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.
  • the server public key 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • her user credentials e.g. her user id and password.
  • 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.
  • 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.
  • some other means e.g. VPN
  • the user device generates an asymmetric key pair.
  • the pair constitutes a private user key and a public user key.
  • 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.
  • the user device determines a hash value of the received password.
  • 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.
  • 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.
  • 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.
  • 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 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 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.:
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • a second logon screen image e.g., a logon screen presented on the user device.
  • 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.
  • the user receives a one-time password in e.g. a SMS.
  • 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.
  • 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.
  • 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.
  • server public key and bank public key are to be understood as synonyms.
  • server private key and bank private key are synonyms.
  • step 6 This two-round trip method is almost identical to the one-round trip method until step 6.
  • 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.
  • 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.
  • 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.
  • the server e.g. home bank
  • the server 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.
  • Logging off a home bank can be an explicit action or performed implicitly, e.g. by closing the browser.
  • 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.
  • Alice herself known as social engineering, "phishing"
  • Alice's user device e.g. PC - known as Trojans, backdoors
  • MITM middle-man
  • 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.
  • 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.
  • Attacking the key store basically means trying to obtain the key for independent use by the hacker without having to cryptoanalyse for it.
  • 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
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the hacker server As an SSL terminator for Alice and propagate traffic through another SSL tunnel to the bank.
  • 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.
  • 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).
  • 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.
  • 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'.
  • the second logon package - if replayed within the same session - will also be caught in the 'state machine'.
  • the logon session protocol thus protects itself effectively against all replay scenarios without any further security measures needed.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Accounting & Taxation (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Finance (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • Software Systems (AREA)
  • Storage Device Security (AREA)

Abstract

Cette invention concerne un procédé pour ouvrir une session sur un dispositif utilisateur vers un serveur comprenant les étapes suivantes : recevoir des justificatifs d'identité authentifiant un utilisateur, par exemple un identifiant d'utilisateur et/ou un mot de passe, au niveau du dispositif utilisateur, générer une paire de clés asymétrique constituant une clé d'utilisateur privé et une clé d'utilisateur publique sur le dispositif utilisateur; recevoir sur le serveur un paquetage; extraire l'identifiant utilisateur et le mot de passe du paquetage, et comparer le mot de passe avec un mot de passe associé à l'identifiant utilisateur extrait sur le serveur; entrer dans l'état consistant à être pré authentifié à la condition qu'il y ait une correspondance entre le mot de passe et le mot de passe associé à l'identifiant utilisateur extrait; déterminer sur le serveur des moyens d'authentification d'utilisateur; envoyer les moyens d'authentification d'utilisateur dans un SMS à un téléphone cellulaire associé ou dispositif utilisateur; recevoir les moyens d'authentification d'utilisateur ou une réponse aux moyens d'authentification d'utilisateur reçus; transférer un mot de passe unique crypté au serveur, et comparer ce mot de passe unique avec un mot de passe unique généré plus tôt, et entrer dans l'état d'une authentification à deux facteurs corrects à la condition que les deux mots de passe unique soient égaux.
PCT/IB2006/054043 2006-11-01 2006-11-01 Ouvrir une session sur un dispositif utilisateur vers un serveur WO2008053279A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/IB2006/054043 WO2008053279A1 (fr) 2006-11-01 2006-11-01 Ouvrir une session sur un dispositif utilisateur vers un serveur

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/IB2006/054043 WO2008053279A1 (fr) 2006-11-01 2006-11-01 Ouvrir une session sur un dispositif utilisateur vers un serveur

Publications (1)

Publication Number Publication Date
WO2008053279A1 true WO2008053279A1 (fr) 2008-05-08

Family

ID=38121798

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2006/054043 WO2008053279A1 (fr) 2006-11-01 2006-11-01 Ouvrir une session sur un dispositif utilisateur vers un serveur

Country Status (1)

Country Link
WO (1) WO2008053279A1 (fr)

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2159762A1 (fr) 2008-08-27 2010-03-03 Deutsche Telekom AG Procédé d'authentification à base de cartes à puce
US8307412B2 (en) 2008-10-20 2012-11-06 Microsoft Corporation User authentication management
US8522010B2 (en) 2008-10-20 2013-08-27 Microsoft Corporation Providing remote user authentication
CN104125230A (zh) * 2014-07-31 2014-10-29 上海动联信息技术股份有限公司 一种短信认证服务系统以及认证方法
US9235697B2 (en) * 2012-03-05 2016-01-12 Biogy, Inc. One-time passcodes with asymmetric keys
US10268843B2 (en) 2011-12-06 2019-04-23 AEMEA Inc. Non-deterministic secure active element machine
CN113472526A (zh) * 2021-06-25 2021-10-01 北京中电华大电子设计有限责任公司 基于安全芯片的物联网设备线路保护方法
US11595375B2 (en) 2020-04-14 2023-02-28 Saudi Arabian Oil Company Single sign-on for token-based and web-based applications
WO2024079340A1 (fr) * 2022-10-14 2024-04-18 Garmer Technologies OÜ Procédé de manipulation sécurisée d'un hachage de mot de passe, système client-serveur le comprenant, et procédés de sécurisation d'un mot de passe fourni par un utilisateur dans un client pour une récupération uniquement par un serveur d'authentification

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030046551A1 (en) * 2001-08-24 2003-03-06 Sean Brennan System and method for accomplishing two-factor user authentication using the internet
US20050050330A1 (en) * 2003-08-27 2005-03-03 Leedor Agam Security token

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030046551A1 (en) * 2001-08-24 2003-03-06 Sean Brennan System and method for accomplishing two-factor user authentication using the internet
US20050050330A1 (en) * 2003-08-27 2005-03-03 Leedor Agam Security token

Cited By (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2159762A1 (fr) 2008-08-27 2010-03-03 Deutsche Telekom AG Procédé d'authentification à base de cartes à puce
US8307412B2 (en) 2008-10-20 2012-11-06 Microsoft Corporation User authentication management
US8522010B2 (en) 2008-10-20 2013-08-27 Microsoft Corporation Providing remote user authentication
US8832806B2 (en) 2008-10-20 2014-09-09 Microsoft Corporation User authentication management
US10268843B2 (en) 2011-12-06 2019-04-23 AEMEA Inc. Non-deterministic secure active element machine
US10728027B2 (en) 2012-03-05 2020-07-28 Biogy, Inc. One-time passcodes with asymmetric keys
US9235697B2 (en) * 2012-03-05 2016-01-12 Biogy, Inc. One-time passcodes with asymmetric keys
CN104125230B (zh) * 2014-07-31 2017-12-15 上海动联信息技术股份有限公司 一种短信认证服务系统以及认证方法
CN104125230A (zh) * 2014-07-31 2014-10-29 上海动联信息技术股份有限公司 一种短信认证服务系统以及认证方法
US11595375B2 (en) 2020-04-14 2023-02-28 Saudi Arabian Oil Company Single sign-on for token-based and web-based applications
CN113472526A (zh) * 2021-06-25 2021-10-01 北京中电华大电子设计有限责任公司 基于安全芯片的物联网设备线路保护方法
CN113472526B (zh) * 2021-06-25 2023-06-30 北京中电华大电子设计有限责任公司 基于安全芯片的物联网设备线路保护方法
WO2024079340A1 (fr) * 2022-10-14 2024-04-18 Garmer Technologies OÜ Procédé de manipulation sécurisée d'un hachage de mot de passe, système client-serveur le comprenant, et procédés de sécurisation d'un mot de passe fourni par un utilisateur dans un client pour une récupération uniquement par un serveur d'authentification

Similar Documents

Publication Publication Date Title
CN109361668B (zh) 一种数据可信传输方法
US8132020B2 (en) System and method for user authentication with exposed and hidden keys
US8949607B2 (en) Digital data authentication
US8185942B2 (en) Client-server opaque token passing apparatus and method
US8209744B2 (en) Mobile device assisted secure computer network communication
US20190238334A1 (en) Communication system, communication client, communication server, communication method, and program
US8321924B2 (en) Method for protecting software accessible over a network using a key device
US20070162961A1 (en) Identification authentication methods and systems
US20090055642A1 (en) Method, system and computer program for protecting user credentials against security attacks
CN108418691A (zh) 基于sgx的动态网络身份认证方法
WO2008053279A1 (fr) Ouvrir une session sur un dispositif utilisateur vers un serveur
Studer et al. Mobile user location-specific encryption (MULE) using your office as your password
WO2018030289A1 (fr) Système de communication ssl, client, serveur, procédé de communication ssl et programme informatique
TWI526871B (zh) Server, user device, and user device and server interaction method
JP2022542095A (ja) 強化された安全な暗号化及び復号化システム
CN110837634B (zh) 基于硬件加密机的电子签章方法
Alzomai et al. The mobile phone as a multi OTP device using trusted computing
US11184339B2 (en) Method and system for secure communication
JP2014081887A (ja) セキュアシングルサインオン方式およびプログラム
ALnwihel et al. A Novel Cloud Authentication Framework
Corella et al. Strong and convenient multi-factor authentication on mobile devices
TWI746504B (zh) 實現會話標識同步的方法及裝置
Staeuble Mitigating Impersonation Attacks on Single Sign-On with Secure Hardware
Asha et al. ACCESS CONTROL MECHANISM BASED MESSENGER APPLICATION FOR SECURE COMMUNICATION USING AES ENCRYPTION METHODOLOGY
Yang et al. Secure Email Login Based on Lightweight Asymmetric Identities

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 06821276

Country of ref document: EP

Kind code of ref document: A1

DPE2 Request for preliminary examination filed before expiration of 19th month from priority date (pct application filed from 20040101)
NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 06821276

Country of ref document: EP

Kind code of ref document: A1