CONNOTECH Experts-conseils Inc.
This document contains guidelines on cryptographic application design when the PEKE or prior session key establishment are considered. The material is organized in two lists matching threats and responses provided by a number of cryptographic techniques fulfilling a common requirement, that is session key establishment. The reader interested in designing a new or upgraded cryptographic application will find indications about protections actually offered by the PEKE technology. A mathematician interested in reviewing the PEKE inherent security should somehow verify that every single protection reported below survives through the scrutiny of mathematical review.
Creating a successful cryptographic application is not a trivial task ([1], [2], [3]). This document meticulously considers threats irrespective of their likelihood in real-world applications (a new design is not yet a real-world application!). The guidelines provided here are intended to expose the effective protection and residual risk of the various techniques for session key establishment. PEKE is the session key establishment technique leaving the designer with the least residual risk. The guidelines provided here include suggestions on what can be done about the PEKE residual risk.
For sake of concision, the language of this document is abstract. From the definition of a threat given here and knowledge of a session key establishment techniques, an application designer should understand why a threat is not countered according to this document. Understanding why a threat is countered by a given session key establishment method may require some more analysis.
Definitions
Any of the session key establishment technique considered here is applicable when a protected session has to be established between a server entity and a client entity. All techniques considered here, but for one, require the server to establish a public/private key pair and to distribute its public key to the client.An execution of a session key establishment mechanism introduces a protected session between the server entity and the client entity. This protected session usually involves other cryptographic mechanisms such as encryption, data integrity algorithms, and digital signatures. These subsequent mechanisms may use portions of the new session key as secret keys. The cryptographic application encompasses the whole protected session plus protections provided by other means (e.g. physical barriers to protect the server private key).
With a carefully designed application, the protections offered by the session key establishment phase extend to the whole protected session. In many cases, a subsequent cryptographic mechanism is needed to counter a residual risk of the session key establishment phase.
The traditional field of secret key cryptography offers some session key establishment techniques (e.g. Kerebos) which are not considered here (the key distribution hindrance of secret key cryptography is deemed too onerous).
Public key cryptography offers a few techniques for session key establishment:
By session key transport, we refer to any form of public key encryption used by the client side to encipher a randomly chosen secret session key. One instance of this technique is RSA encryption.By session key exchange, we refer to either the Diffie-Hellman cryptosystem or the PEKE technology. These two techniques share a number of common properties. When these two techniques behave differently, each one is considered separately.
The first list below indicates the crude reaction of these session key establishment techniques to some defined threats. A threat reported in this list as "no protection" may vanish when considering the whole application (e.g. a replay attack in a highly interactive application could be considered as a remote possibility, or could be countered by a digital signature during the protected session). Conversely, an effective protection may be lost by an ill-designed application (e.g. the session key is used with a weak data integrity algorithm).
Note: when a given threat is specifically "targeted" to either the server or the client, the target is the party which participated legitimately in the protected session, (as if there were no recourse against neither the adversary nor the legitimate party on behalf of which the adversary acted).
Client role sham. An adversary attempts to participate in a protected session with a legitimate server, pretending to be a legitimate client.
Denial of service targeted at the server. An adversary induces a server to proceed through a protected session and leaves the server under the impression that everything went fine despite the fact that the legitimate client was not involved (contrary to the client role sham, the adversary does not acquire insight into the client-server relationship).
Replay attack targeted at the server. An adversary records a protected session, or a portion thereof, and attempts to re-use it to its advantage in the context of a client role sham.
Server role sham. An adversary attempts to participate in a protected session with a legitimate client, pretending to be a legitimate server.
Denial of service targeted at the client. An adversary induces a client to proceed through a protected session and leaves the client under the impression that everything went fine despite the fact that the legitimate server was not involved (contrary to the server role sham, the adversary does not acquire insight into the client-server relationship).
Replay attack targeted at the client. An adversary records a protected session, or a portion thereof, and attempts to re-use it to its advantage in the context of a server role sham.
Cheating on server public key. As a preliminary step in another attack, an adversary induces a client to use (as the public key in a given session establishment) a key different from the legitimate server's public key.
Passive eavesdropping. An adversary overhears the protected session and records it for later analysis. Actually, the passive eavesdropping threat refers to data protection offered by secret key encryption after completion of the session key establishment phase.
Data modification. Using some means to modify the ciphertext messages of the protected session, an adversary attempts to modify the meaning of these messages. Actually, the data modification threat refers to data protection offered by secret key data integrity algorithms after completion of the session key establishment phase.
Server private key compromise. After obtaining the private key of the server (without this fact being noticed by legitimate participants), an adversary attempts to sham the server role, to passively eavesdrop a protected session, or otherwise attack one or more protected sessions.
Active eavesdropping. In the simple form of active eavesdropping, the adversary intercepts an encrypted secret key, decrypts it for its own purpose, and encrypts it again for the legitimate server. Neither the legitimate client nor the legitimate server notice the interception. Once the interception is achieved, the adversary passively eavesdrop the remaining protected session and analyzes it using the intercepted session key.
Note: This threat is technology-intensive, but much less than the intricate active eavesdropping.
Intricate active eavesdropping. In the intricate form of active eavesdropping, the adversary intercepts messages between a legitimate client and a legitimate server. The adversary establishes two session keys, one between the client and the adversary, and one between the server and the adversary. Neither the legitimate client nor the legitimate server notice the interception and the key substitution. During the whole protected session, the adversary transposes in real-time cryptographic messages between the two session keys.
Note:This threat is highly technology-intensive.
It is assumed that once a session key is established, 1) an encryption technique is used if confidentiality protection is needed, and 2) a data integrity technique is used if data integrity protection is needed. This justifies the "effective protection" response to passive eavesdropping and data modification threats in the list above.
The authentication capability of session key transport and PEKE is through an inference rather than through positive authentication: the client side is only ascertained that if the protected session succeeds, the remote party was the legitimate server. The client knows that the protected session succeeded when something is achieved by the server, requiring the knowledge of the session key. For instance, this something can be the very completion of a transaction requested by the client, or an explicit digital signature of a portion of the session key by the server. The inference nature of the authentication capability creates a "no protection" response to denial of service attack targeted at the client (in the list above).
The list below indicates the residual threats for each session key establishment method. For PEKE, the significance of, and countermeasures for each residual threats is then discussed.
Client role sham. This threat is the classical access control issue. The countermeasures can be password-based (e.g. PIN-based) or based on digital signatures. For password-based countermeasures, encryption and data integrity protection using the session key are suggested. Interception of the password when entered by the user should be prevented by some means. For countermeasures based on digital signatures, a public key has to be set up for each client and a portion of the session key should be digitally signed with the private counterpart of the client's public key. The private counterpart should be strongly protected from any form of disclosure.
Denial of service targeted at the server. The countermeasures applicable to the client role sham are effective for denial of service targeted at the server as well.
Denial of service targeted at the client. As a countermeasure, the client needs an acknowledgement that he can recognize as genuinely originating from the server. This can be provided with application-specific means either within the protected session, or independently. One way to provide an acknowledgement in the protected session is with a digital signature of a portion of the session key.
Cheating on server public key, server role sham. This is the classical issue of a cryptographic bound between a public key and an entity. When a number of servers are participating in an application, the issuance of a security certificate to each server is a classical solution, but requires the public key of the certification authority to be protected (as if there was a single server and no security certificate). Thus, there is always a cornerstone public key that has to be set up by a trusted party and protected by strong data integrity protection during transmission to the client and storage within the client system. The actual security requirements should be taken into account in the application design. For instance, a voice telephone session is less threatened by a server role sham than an electronic funds transfer transaction embedding the account holder's PIN.
Server private key compromise. This threat is the classical broken private key threat for public key cryptography. The server system should strongly protect its private key from any form of disclosure.
Cheating on server public key, intricate active eavesdropping. The countermeasures applicable to the cheating on server public key are effective for this threat as well. A digital signature of a portion of the session key, generated by one party and verified by the other party, is another possible countermeasure (admittedly, it requires an authenticated public key for the signature). The likelihood of this combination of threats is application-dependent. Three factors should be taken into account: 1) the difficulty of achieving the intricate active eavesdropping, 2) the integrity protection of the server public key, and 3) the advantage to be gained by this type of attack.
[1] Anderson, Ross J., Liability and Computer Security: Nine Principles, in Computer Security - Esorics '94, Third European Symposium on Research in Computer Security, November 1994, LNCS 875, Springer Verlag, pp 231-245
[2] Abadi, Martín, Needham, Roger, Prudent Engineering Practice for Cryptographic Protocols, in 1994 IEEE Symposium on Research in Security and Privacy, IEEE, 1994, pp 122-136
[3] Anderson, Ross J., and Needham, Roger, Robustness Principles for Public Key Protocols, in Advances in cryptology, CRYPTO'95, LNCS 963, Springer Verlag, 1995, pp 236-247
CONNOTECH Experts-conseils Inc.
9130 Place de Montgolfier
Montréal, Québec, Canada, H2M 2A1
Tél.: +1-514-385-5691
Fax: +1-514-385-5900