CONNOTECH Experts-conseils Inc.

Information Security Principles of the SAKEM Procedure

Say "Open, Sesame" to Electronic Identification!

Table of Contents

    Outline / Operational / Strategy / Cryptography / Programming

Introduction

"SAKEM" stands for "Secret Authentication Key Establishment Method." It is useful for the issuance of electronic identification devices. SAKEM adresses cryptographic key management issues. More specifically, the SAKEM procedure addresses the need to establish, or renew (e.g. after security breach), the very first shared secret key between two parties (e.g. a client and a financial institution in an on-line banking service arrangement). The SAKEM procedure also addresses the secure loading of cryptographic key material in hand held memories in the form of smart cards, security tokens, and the like.The present document covers important security aspects of the SAKEM procedure, namely those that require management attention. Another document entitled "Cryptographic Processing in the SAKEM Procedure" covers the involved mathematical aspects of the underlying cryptography.

A registration procedure provides the applicant with secret authentication information. This secret can be a Personal Identification Number (PIN), a private key for a digital signature algorithm, or a secret cryptographic key to be shared between the applicant and the issuer. While a PIN can be remembered by a normal person, the two other forms of authentication secret require a digital memory of some sort. The SAKEM procedure applies to the registration process when a shared secret authentication key is used, as in the case of the traditional MAC-based (Mesage Authentication Code) transaction authentication.

Ultimately, transaction authentication is effective if it secures the legal bound between a bank account withdrawal and the account holder liability, while barring the access to the funds by defrauders. Since the account holder is a legal person rather than a digital apparatus, the required chain of evidence is a two-tiered authentication bound: 1) the logical bound between the account holder (or the account holder agent) and a cryptographic operation performed by a digital apparatus, and 2) the bound between this said cryptographic operation and the transaction historic records of the financial institution. The SAKEM procedure addresses these two aspects of transaction authentication.

Some operations required in the SAKEM procedure are performed by computers. Such operations are called "controlled computer operation" but are nonetheless considered as acts of either the applicant or the issuer. In practice, these operations are performed by a computer "under the control" of either the applicant or the issuer. The degree of effective control on any computer operation may influence the security of the whole secret key establishment method.

The inputs and outputs of controlled computer operations are often stored in digital memories. Then, again, uninterrupted possession and/or control over the use of these digital memories may influence the security of the whole secret key establishment method.

    Outline / Operational / Strategy / Cryptography / Programming

Definitions and context

Issuer

The issuer is the organization that issues secret keys for identification purposes.

The issuer is a service organization whose trustworthiness should be commensurate with the issues at stake. The issuer database is secured using the ususal computer system security techniques where a single organization may exert effective control of the system security. Typically, this will include cryptographic processing capabilities closely associated with the database in such a way that secret keys are not accessible to issuer personnel.

    Outline / Operational / Strategy / Cryptography / Programming

Applicant

The applicant is the new customer, client, subscriber, or member to whom a secret key will be issued.

Some security precautions are exepected from the applicant in order to protect his own interests. The applicant's interests are vested in the secret key to be issued. Accordingly, carelessness from the part of the applicant is detrimental, as much when he takes part in the SAKEM procedure as when he uses the secret key for routine transactions thereafter.

    Outline / Operational / Strategy / Cryptography / Programming

Identification token

An identification token is a portable memory device, e.g. a smart card, that may be used to store the secret key issued to the applicant.

The small size of the identification token relieves the applicant from the obligation to control the access to a fixed apparatus like a computer system, or a luggage-size apparatus like a portable personal computer.

The SAKEM procedure allows the remote secret key initialization and loading into the identification token with sensible identity verification mechanisms.

    Outline / Operational / Strategy / Cryptography / Programming

Reduced cost of highly secure electronic transactions

SAKEM advances the affordability of highly secure electronic transactions.

The SAKEM procedure alleviates the traditional burden of secret key distribution, and thus suggests the avoidance of the public key infrastructure. This is a key success factor for the SAKEM procedure: the installed base of secret key cryptography applications is very large, and the public key cryptography comes with hidden costs, incompatibilities, and other burden that would be too long to list. The SAKEM procedure makes internal and temporary use of public key cryptography, using the least compute-intensive public key algorithm. In other words, SAKEM takes advantage of the public key cryptography where it is most beneficial and otherwise adheres to the current installed base.

    Outline / Operational / Strategy / Cryptography / Programming

Call centers

Doing business over the telephone is a general trend in service industries.

Actually, the SAKEM requirement is a single conversation between an agent of the issuer and the applicant. During the conversation, this agent must accept or reject the application request from a new applicant. From a security perspective, the employee or agent is relatively empowered in this context. In call centers, the issuer agents typically access customer data on a need-to-know basis through on-line terminals with controlled access to software functions, and with auditing to deter or sanction frauds that agents might conceive or commit.

    Outline / Operational / Strategy / Cryptography / Programming

Broad distribution of low cost software and electronic devices

SAKEM fits well in the ever-decreasing up-front price charged for software, computers, and other electronic equipment.

The security of the SAKEM procedure does not require any personalization of software or identification token before delivery to the applicant. As a consequence, the only remaining threat from the distribution channels is the fraudulent introduction of bogus software. This threat is addressed in the preparation of the applicant registration software.

    Outline / Operational / Strategy / Cryptography / Programming

Preparation steps by the issuer

The issuer gets a private/public key pair for a public key cryptosystem.

The issuer needs a private/public key pair for the PEKE public key cryptosystem. The requirements for PEKE in this respect are very similar to the requirements for RSA, the most widely known public key cryptosystem. This key generation is done very occasionally with the help of a computer utility, and starting from a secret random source. It is very important that the private component of the private/public key pair be promptly stored in the issuer's secure computer system where the SAKEM cryptographic processing is going to be run, and that a split-key backup be taken for disaster recovery purposes (normally, the key generation utility is run by the very issuer's secure computer system where the key is used).

The private/public key pair is used for initial confidentiality of the secret key, and for short term authentication, but not for non-repudiation. This means that the secrecy of the private component is very important, but an accidental disclosure to a fraudor would not jeopardize SAKEM registrations completed prior to the disclosure, unless they were originally eavesdropped and recorded by the fraudor. There is no need to obtain a security certificate for the public component of the issuer's private/public key pair.

    Outline / Operational / Strategy / Cryptography / Programming

The issuer prepares an applicant registration software.

In the preparation of the registration software, it is important to prevent the creation of unauthorised versions of the software that could be substituted for the legitimate version. The issuer public key is the focal data element that must be protected against unauthorised modification. Equally important is the release of the complete software package. For more information, see a document on the rationale for using a proprietary algorithm for software integrity protection.

If the issuer public key must be strongly protected against malignant modifications, other data might be protected as well. It is advisable to prepare a comprehensive set of issuer's parameters, including the electronic address where the registration request should be sent, and the telephone number for the issuer call center.

In summary, two approval processes are required, respectively for to release the complete software pacakge, and for to prepare the set of issuer's parameters. These approval processes should be restricted to properly authorized personel. With the suggested scheme using the Frogbit semi-proprietary algorithm, the approval processes are as follows:

1. as a preliminary step, creation of a secret semi-proprietary algorithm in source code format;
   
   
2. still as a preliminary step, compilation (and "object module linking" linking whenerer appropriate) of secret source-code into:
   
   2a) object code (decryption or data recovery) for each target computer environment in which the registration program will run, and
   
   2b) an executable utility (data concealment) for the set of issuer's parameters;
   
   
3. for software release, the "object module linking" of application modules plus modules generated in step 2a) (done in each target computer environment);
   
   
4. for preparation of the set of issuer's parameters, an data concealment step using the utility from step 2b).

    Outline / Operational / Strategy / Cryptography / Programming

The issuer releases the applicant registration software.

The SAKEM procedure is not based on any security-related contribution from the intermediaries in the distribution chain for the registration software.

    Outline / Operational / Strategy / Cryptography / Programming

Preparation steps by the applicant

The applicant obtains the applicant registration software.

The golden rule for computer virus protection is "always acquire software from reputable source." The golden rule applies to the registration software needed by the applicant for to use the SAKEM procedure. What is expected from a reputable software source is the precautions described in a previous section.

    Outline / Operational / Strategy / Cryptography / Programming

The applicant obtains a blank identification token.

The SAKEM procedure is not based on any security-related contribution from the intermediaries in the distribution chain for the identification token.

    Outline / Operational / Strategy / Cryptography / Programming

Computerized portion of the SAKEM procedure

The applicant starts the registration software.

The registration software needs the set of issuer's parameters. To read them, and to check their integrity, the software reverses (decrypts) the data integrity mechanism that was applied when the software was prepared.

The registration software uses the issuer's public key as a starting point for the cryptographic protections. This guarantees that only the issuer will be able to reverse the cryptographic protections applied during the registration program execution. This refers to the main purpose of the registration software as explained in the next three sections.

The registration software includes a private random source. The following characteristics are required for the output from the random source:

1. the successive draws from the random source must be (mutually) unpredictable,
   
   
2. the draws for different users of the registration software must be (mutually) unpredictable,
   
   
3. it must be impossible to deduct a draw from a complete backup of the computer taken just before an execution of the registration software,
   
   
4. it must be impossible to deduct a draw from a complete backup of the computer taken just after an execution of the registration software.

To achieve these goals, some truly random data must be input to the random source software component. The PGP software (a widespread e-mail encryption utility) uses keyboard input from the user as a source of truly random data (this user input is not used for any other purpose). Unless keystroke timing measurements are also taken as random data, there is always the danger that a user is fraudulently instructed to type some specific text instead of truly random characters (then, requirement 3 would not be met). With the PEKE cryptosystem, if the initiator's message is sent from a system with a reliable random source, the whole SAKEM cryptographic processing is less sensitive to failures of the registration software random source.

The registration software uses the PEKE cryptosystem to generate an internal secret key. Because it knows the private component of the private/public key pair, the issuer is later able to recover the value of the internal secret key. The PEKE responder message makes the required junction between the registration software computer environment and the issuer data processing center.

    Outline / Operational / Strategy / Cryptography / Programming

The applicant chooses and types a pass query and a pass reply.

The pass query and pass reply secure the bound between 1) the secret key to be loaded in the identification token, and 2) the later conversational portion of the SAKEM procedure (when the applicant's identity is verified).

By keeping secret the pass query, the applicant gets assurance that the first person who can thereafter pronounce it is an issuer agent; this level of assurance being proportional to the applicant's trust in the issuer operational integrity. Conversely, by keeping secret the pass reply, the applicant protects himself against an impostor who could otherwise

1. intercept and delete the legitimate applicant request during transit to the issuer data processing center;
   
   
2. using the usual computerized portion of the SAKEM procedure, submit a request of his own under the name of the legitimate applicant and with the same pass query and pass reply;
   
   
3. wait for the applicant to state his identification data in the conversational portion of the SAKEM procedure corresponding to the false registration request; and
   
   
4. fraudulently use the identification token obtained in step 2.

Without a pass reply, the above sham would be easier to mount. The idea is to induce the applicant-victim into believing that he should answer identity verification questions despite the fact that no (legitimate) registration request was actually received by the issuer.

    Outline / Operational / Strategy / Cryptography / Programming

The secret key is loaded in the identification token.

From the internal secret key, the registration program derives the identification key (long term secret key to be shared for identification purposes between the applicant and the issuer). The simplest derivation scheme is adequate: the first 112 bits of the internal secret key are used for the identification key.

Then, this identification key is loaded in the identification token. There are numerous variations possible for the key loading operation. In this section, a single example is detailed. This sample scheme is an often overlooked application of elementary cryptographic principles.

The registration program splits the identification key to be loaded into three components as follows:

1. the registration program accepts a (newly selected) local applicant's PIN (that is not stored in the issuer database), and the first component is calculated as k1=hash(PIN) where "hash" is a key-less hash function (e.g. MD5 or SHS);
   
   
2. the registration program gets the second component k2 from its private random source, and the registration program loads the key component k2 into the token memory;
   
   
3. the third component is computed as k3=secret_key XOR k1 XOR k2, where secret_key is the secret identification key and XOR is the exclusive-or operation, and the registration program loads the key component k3 into a computer file on the local hard disk.

This gives three-factor security: access to the secret identification key requires 1) knowledge of the local applicant's PIN (for k1=hash(PIN)), 2) access to the token memory (for k2), and 3) access to the computer file (for k3). In routine electronic transactions, once these three preconditions are met, the identificatio key is computed with secret_key=k3 XOR k1 XOR k2. One can view k3 as the ciphertext for the secret identification key in a double encryption scheme, the encryption algorithm being the one-time pad, and the two keys being k1 and k2.

    Outline / Operational / Strategy / Cryptography / Programming

The registration programs sends a registration request message to the issuer data processing center.

Just like there was a key derivation scheme for the identification key from the internal SAKEM secret key, some secret keys are obtained by the registration program for other purposes. Two such keys are obtained, each being 112 bits long (for a grand total of 336 bits). The corresponding purposes are, respectively:

1. the MAC'ing of registration data using a first 112 bits key,
   
   
2. the encryption of registration data using a second 112 bits key.

Thus, the SAKEM procedure uses an hybrid public/secret key scenario: the PEKE cryptosystem is the public key portion that provides the internal secret key, and keys derived from this internal secret keys are used in conventional secret key algorithms.

The registration request contents includes notably the pass query and the pass reply. Other application-specific data may be included as well (e.g. the applicant account number). This contents is first MAC'ed, and then encrypted using the above two keys. The resulting ciphertext is adjoined to the PEKE responder message and any required cleartext indication of the context in which the registration request should be processed (e.g. a reference to the PEKE intiator's message, or a copy of the PEKE initiator's message). Together, these data elements constitute the registration request message that is sent electronically to the issuer's data processing facilities.

After the registration program has loaded the identification key and completed the preparation of the registration request message, all keys and temporary variables should be erased from the computer memory.

    Outline / Operational / Strategy / Cryptography / Programming

The issuer data processing center receives the request, processes it and files the application request in the issuer database.

The cryptographic processing done in the issuer data processing center is the systematic reversal of the processing originally done by the registration program. In sequence, this is:

1. the reversal of the PEKE cryptosystem, resulting in the internal secret key;
   
   
2. the identical derivation of three keys as originally done by the registration program: secret identification key, key for MAC'ing, key for decryption;
   
   
3. the decryption of the registration data;
   
   
4. the MAC verification for the registration data.

Then, the registration data can be stored in the issuer secure database: the secret identification key might be protected with the same mechanisms as the master key of any terminal equipment, and the pass query and pass reply might be protected with mechanisms applicable to the most sensitive data in a customer record.

An issuer agent may, at any time thereafter, be assigned the task of validating the applicant's identity with a personal conversation.

    Outline / Operational / Strategy / Cryptography / Programming

Conversational portion of the SAKEM procedure

A voice contact is established between applicant and issuer agent.

Ideally, the adage "know your customer" taught to loan managers in lending institutions should be applied to the verification of applicant's identity in the SAKEM procedure. The strict application of this adage would require the applicant to visit a branch of the issuer where members of the personel know the applicant, or to have a telephone conversation with an issuer agent who personally knows him. In practice, the value of the electronic registration may not justify such disturbance for the applicant, and a telephone conversation with any issuer agent may be sufficient.

    Outline / Operational / Strategy / Cryptography / Programming

The applicant and the issuer agent mutually verify the knowledge of pass query/reply by the other person in the conversation.

The issuer agent should pronounce the pass query to the person he is speaking with, and then ask this person to pronounce the pass reply. In the normal case where the pass reply verification is successful, and assuming that the applicant did not reveal the pass reply to anyone, the issuer agent is assured that the person he is speaking with is the one who entered the pass query and reply when the applicant's secret key was generated.

    Outline / Operational / Strategy / Cryptography / Programming

The issuer agent verifies the identity of the applicant.

The personal information used for the verification of identity should be somehow anecdotal in order to reduce the chances that someone who knows the applicant is unlikely to be able to answer the issuer agent questions. If computer data is used for this purpose, it should be circulated on a "need-to-know" basis (e.g. displayed to the issuer agent only after he reported that the person he is speaking with rightfully pronounced the pass reply).

This verification of identity binds the applicant to the secret identification key generated by the SAKEM cryptographic protocol. If the verification of identity is successful, the issuer agent is assured that the person he is speaking with is indeed the applicant for who the secret key registration was awaiting validation in the issuer's database.

    Outline / Operational / Strategy / Cryptography / Programming

The issuer agent flags the registration as being validated in the issuer database.

The permission to update the status of any outstanding registration request should be granted only to issuer agents who actually verify the applicant's identity. In addition, auditing mechanisms should be put in place, and their existence should be explained to the agents. Otherwise, fraudors may attempt to bride an agent for accepting a fraudulent registration request without the proper verification of identity. In the auditing procedures, it is important to follow-up on failed or deleted registration requests. If any such abandonned registration request is followed by a successfully completed one with closely related pass query and reply, a fraud attempt should be suspected and the agent who flagged the failure or deletion should be considered suspect.

    Outline / Operational / Strategy / Cryptography / Programming

[ CONNOTECH home page: http://www.connotech.com/ | SAKEM web page: http://www.connotech.com/sakem.htm | about us | web editorial policy | e-mail to: info@connotech.com ]

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