SAKEM Leading Edge Security

Return->

The SAKEM procedure itself is an hybrid cryptographic application that makes internal use of strong cryptographic algorithms. This means that there is a Public Key Cryptography (PKC) aspect and a Secret Key Cryptography (SKC) aspect.

The Public Key Cryptography (PKC) Aspect

A PKC primitive is the backbone of the SAKEM security at the on-line registration phase. Only the issuing organization needs to establish a pair of public and private keys. The PKC primitive must establish an internal secret key between the applicant's system, device or terminal and the issuer data processing center.

Smallest requirements for PKC accelerator circuits

There is a single point in the system architecture where the private key is needed for a PKC computation; this point is located in the issuer data processing center. The volume of PKC computations is never expected to be very large (SAKEM is for initial registration, routine transactions do not use the issuer public key). Accordingly, any budget for special purpose PKC hardware is best spent for devices featuring the highest security (throughput being a secondary requirement), in order to prevent compromise of the issuer public key (a very serious security incident), and the associated embarassement and operational difficulties.

There is no requirement for a PKC accelerator circuit on the device used by the end-users, because the applicant's side of the PKC computation is usually the least intensive.

Many PKC options for the choice of a PKC primitive

It is sufficient for the PKC primitive to establish an internal secret key. Thus, the possible options are many. The emerging standard IEEE P1363 formalizes a general model for key agreement schemes, and proposes a few practical PKC primitives from the discrete logarithm family (and their elliptic curve variants as well). The IEEE P1363 text does not contain any key agreement alternative from the integer factorization family, but some do exist, notably Probabilistic Encryption Key Exchange (PEKE, see [1]). The Okamoto-Uchiyama (OU) cryptosystem appears as an emerging third PKC family (see [2]).

The selection of a PKC alternative for SAKEM may consider the various vulnerabilities of public key protocols, such as man-in-the-middle attacks, replay attacks, chosen ciphertext attacks, malicious public key replacement, pseudo-random generator failures and so on (see also [3]). Fortunately, the task assigned to the PKC primitive in the SAKEM procedure is relatively straightforward, so the selection of a PKC primitive is not as challenging as with more comprehensive uses of the PKC.

CONNOTECH suggests the use of PEKE as the PKC in the context of the SAKEM procedure, and provides a supporting threat analysis (see annexe E of [4]).

Minimal Interoperability Requirements.

Because the scope of a SAKEM implementation is limited to the registration phase of a security application, and such registration is limited to a specific issuer, there are minimal interoperability requirements for the PKC used in a particular use of the SAKEM procedure. Essentially, the interoperability requirements lie between the applicant's system, device or terminal and the issuer data processing center, including the PKC implementation at both ends. SAKEM imposes no definite interoperability requirements among different issuers (such requirements may be imposed by other considerations, e.g. standards for a particular type of secure device).

Overall, the SAKEM procedure gets the largest incremental benefits from the minimal use of the PKC technology.

Return->

The Secret Key Cryptography (SKC) Aspect

A small number of SKC techniques are needed in the SAKEM on-line registration phase to secure the data submitted by the applicant to the issuer. The cryptographic keys for these SKC algorithms are derived from the internal secret key established with the PKC primitive. The secret authentication key which is the outcome of the SAKEM procedure is also derived from the internal secret key. The PKC primitive and the key derivation method are secure (they prevent the recovery of any other derived key from the knowledge of a first one).

Strong encryption is provided with a block encryption algorithm, namely triple-DES used in the CBC mode of operation (double length key). Also, integrity protection is provided the classical MAC processing, namely RIPE-MAC3 (essentially, RIPE-MAC3 is the triple-DES algorithm with double-length key used for MAC processing, see [5]). This is a very straightforward arrangement, which shouldn't be put into question from the perspective of strong commercial security mechanisms. Obviously, variations of this scheme are possible, and the forthcoming replacement of (triple-)DES by one of the AES candidates may be considered after the AES selection process is completed.

In an attempt to accomodate the export regulations and other regulatory controls on the use of strong cryptography, a portion of the on-line registration data is covered by the integrity protection but not encrypted, and the SAKEM implementation details can be taylored by determining which data elements are encrypted and which are not. However, in any actual case of fielding the SAKEM procedure, the influence of crypto-regulations should be assessed properly.

In summary, the SKC portion of the SAKEM procedure implementation offered by CONNOTECH uses classical arrangements of mechanisms, without compromise on the strength of algorithms.

Return->

Reference

[1] Moreau, Thierry, Probabilistic Encryption Key Exchange, Electronics Letters, Vol. 31, number 25, 7th December 1995, pp 2166-2168

[2] Okamoto, T, and Uchiyama, S., A New Public Key Cryptosystem as Secure as Factoring, Eurocrypt'98, pp 308-318, Springer-Verlag, 1998

[3] Anderson, Ross J., and Needham, Roger, Robustness Principles for Public Key Protocols, in Advances in cryptology, CRYPTO'95, LNCS (Lecture Notes in Computer Science) 963, Springer Verlag, 1995, pp 236-247

[4] Moreau, Thierry, Automated Data Protection for Telecommunications, Electronic Transactions and Messaging using PEKE Secret Key Exchange and Other Cryptographic Algorithms, Technology Licensing Opportunity, revision 1.1, CONNOTECH Experts-Conseils Inc., Montréal, Canada, March 1996 - The annex E of this reference is available on-line.

[5] Bosselaers, Antoon, and Preneel, Bart (editors), Integrity Primitives for Secure Information Systems, Final Report of RACE Integrity Primitive Evaluation, RIPE-RACE 1040, Springer, LNCS (Lecture Notes in Computer Science) 1007, 1995