CONNOTECH Experts-conseils Inc.

Project Strategy Options for the SAKEM Procedure

Say "Open, Sesame" to Electronic Identification!

Table of Contents

    Outline / Operational / Security / Cryptography / Programming

Introduction

"SAKEM" stands for "Secret Authentication Key Establishment Method." It is useful for the issuance of electronic identification devices. The general function of a registration procedure such as SAKEM is to make a given client known by the service organization in such a way that the subsequent routine processing of transactions is automated and efficient. The SAKEM procedure can be used in a myriad of different application areas, and this document focuses on project strategy options and flexibility of the procedure.

    Outline / Operational / Security / Cryptography / Programming

Definitions and context

Issuer

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

The issuer can be any service provider using electronic means for identification purposes. The SAKEM procedure may also be used to issue electronic keys to employees for unlocking doors, in which case the issuer would be the lockmaster department in charge of the premises.

    Outline / Operational / Security / Cryptography / Programming

Applicant

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

The applicants have access to electronic apparatuses through which they conduct their ordinary activities. This can be anything from their own personal computer, to a bank ATM (Automated Teller Machine), or to a "smartphone". A distinctive feature of the SAKEM procedure is the high security level even in the case of insecure personal computers. This property is of paramount importance with the growing use of Internet for electronic commerce. Moreover, in applications with multimedia kiosks in shopping malls, the SAKEM procedure allows shared kiosks with minimal security overhead.

    Outline / Operational / Security / 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 SAKEM procedure is also applicable if the generated secret key is either stored on the computer hard disk, or displayed in human-readable form for manual data entry through the keyboard of another apparatus.

If an actual token is used, its shape can be very diverse: like a credit card, or in a form suitable for attachment on a key ring, or any other small size format.

There must be a way of transfering a secret key value from the computer running the computerized portion of the SAKEM procedure to the identification token. There may be an appropriate slot, connector, or receptacle on the applicant's personal computer. Alternatively, this computerized portion may be run from a computer station temporarily available to the applicant for the SAKEM procedure. Some identification token come with a small keyboard, in which case the user may manually transfer the secret key.

An identification token contains at least a digital memory. When the digital memory in a token is physically protected against unauthorized reading or modification, its intrinsic security is increased. Actually, this protection is effective only when the token embeds a microprocessor that makes a cryptographic access control to the contents of the digital memory. The foremost example is the smartcard category with an intermediate level of sophistication.

The sharing of an identification token between multiple unrelated issuers is another opportunity created by the SAKEM procedure. Indeed, since it is the applicant that initiates the secret key loading into the token, he may load as many independent keys as the token would allow. Multiple-use on a single card is a long-promised feature of the smart-card technology and the SAKEM procedure is a good step in this direction.

The cost-effective and privacy-scrupulous use of biometric identification data is yet another opportunity of the SAKEM procedure. It's easy to think of a shopping mall kiosk that would include a voice recognition software. The characterisitcs of an applicant's voice would be stored on his smartcard, but nowhere else. The kiosk would use the smartcard only if the voice matches the characteristics found on the card. The SAKEM procedure allows the applicant to use the card with the issuers of his choice. The issuers need no voice recognition technology in their systems: from their perspective, the identification is still based on a conventional secret key.

Some identification tokens are special-purpose calculators providing one-time passwords in a challenge-response protocol for user identification in computer networks. Whenever the secret key of such calculators can be loaded by the applicant himself, the SAKEM procedure is applicable.

    Outline / Operational / Security / Cryptography / Programming

Reduced cost of highly secure electronic transactions

SAKEM advances the affordability of highly secure electronic transactions.

This is achieved with the SAKEM internal use of a public key cryptosystem, namely the PEKE cryptosystem. Actually, the PEKE cryptosystem is one of three alternate cryptosystems (for the cryptography expert, the three options are compared in an hypertext document entitled "Public Key Cryptosystem Options for the SAKEM Procedure").

    Outline / Operational / Security / 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 employee or agent of the issuer, and the applicant. This conversation may occur over the telephone or during a personal visit to a branch location of the issuer.

    Outline / Operational / Security / 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 freedom of choice for the distribution of software and identification tokens is unique to the SAKEM procedure. Before the applicant starts the SAKEM procedure, neither software nor hardware has to be "prepared to order" for him. Accordingly, any distribution channel can be used, including for instance the download of software from an Internet site by the applicant.

    Outline / Operational / Security / Cryptography / Programming

Preparation steps by the issuer

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

This preparation step is governed by the choice made for the cryptographic aspects of the SAKEM procedure implementation. The SAKEM procedure does not require a "Certification Authority" (CA) for the issuance of a security certificate for this private/public key pair.

    Outline / Operational / Security / Cryptography / Programming

The issuer prepares an applicant registration software.

The applicant registration software must be able to load a secret key into the identification token used in a particular application of the SAKEM procedure. This executable program may be embedded in an electronic apparatus like a POS terminal instead of being run by a general purpose computer.

The applicant registration software may be 1) a custom software development for a single issuer, or 2) a software development for a specific type of identification token. In either case, the issuer must prepare a set of issuer-specific configuration parameters such as the public component of the issuer's private/public key pair. This set of parameters may include any identification data for the issuer, like the electronic mail address where the secret key registration should be sent. With the custom software development (alternative 1), the set of configuration parameters is embedded in the software in any way that fits. With the token-type specific software (alternative 2), the set of configuration parameters is stored in a configuration file.

In planning the software development strategy, one must account for the threat of computer viruses or bogus software. This is an area where the science of cryptology doesn't provide quantifyable solutions, so ad hoc security software solutions always remain (sometimes tacitly embedded in de facto standards adopted by the industry). Ultimately, the idea is to increase the difficulty of reverse-engineering executable code. Here are the alternative courses of action:

1. Do nothing about the threat of computer viruses or bogus software. If the applicant registration software is run by proprietary hardware, this could be a reasonable approach.
   
   
2. Develop a proprietary algorithm to conceal the data structure of the issuer's configuration parameters.
   
   
3. Use the Frogbit data integrity algorithm as a strating point for ad hoc development of a "semi-proprietary" algorithm. This requires custom software development but nonetheless uses a publicly disclosed cryptographic scheme.
   
   
4. Affix a digital signature to the set of issuer's configuration parameters. By itself, this alternative merely shifts the bogus software threat: because a public key is needed for to verify a digital signature, the vulnerable portion of the software package moves from the issuer's configuration parameters to the signature verification public key. This leads to the following variants:
   
   4a) No special arrangement is made to protect (against the bogus software threat) the public component of the private/public key pair used for the digital signature operation. This is almost like alternative 1.
   
   4b) A Certification Authority (CA) backs the digital signature operation (with a security certificate) and the "off-the-shelf" protection (against the bogus software threat) offered by this CA is used.
   
   4c) A chain of security certificates, from various CAs, is packaged with the issuer's configuration file and the applicant is expected to trust at least one the CA for which the public key integrity is independently verified. This corresponds to the grandiose view of the public key infrastructure, except that the SAKEM procedure always eliminates the need for applicant's security certificates.

As a summary comment, the alternatives 3 or 2 are handy custom solutions, while alternatives 4b) or 4c) are more oriented towards out-sourcing to established security companies.

    Outline / Operational / Security / Cryptography / Programming

The issuer releases the applicant registration software.

Any distribution channel can be used, including for instance the download of software from an Internet site by the applicant.

    Outline / Operational / Security / Cryptography / Programming

Preparation steps by the applicant

The applicant obtains the applicant registration software.

Any distribution channel can be used, including for instance the download of software from an Internet site by the applicant.

Since there is no particular security issue at software installation time, it is simple to have the software available for self-service use at kiosks installed in shopping malls.

    Outline / Operational / Security / Cryptography / Programming

The applicant obtains a blank identification token.

It is not before the applicant decides to go through the SAKEM procedure that an identification token is loaded with a useful secret key. According to this principle, there are many options as to how the applicant gets an identification token.

When it is commercially attractive, it is possible to send unsolicited identification tokens to potential applicants. The legal notices about the rights and liabilities associated with the identification token may be displayed to the applicant when he decides to go through the SAKEM procedure.

Alternatively, the SAKEM procedure can update an identification token already in possession of the applicant. This can occur besause a new service is requested by the applicant, maybe from a new issuer. Also, following a suspected security breach, or on a periodical basis, it may be desirable to renew the secret key used by an issuer for this applicant.

    Outline / Operational / Security / Cryptography / Programming

Computerized portion of the SAKEM procedure

The applicant starts the registration software.

Access to issuer's configuration parameters

When the applicant starts the registration software, it is the last chance for the set of issuer's configuration parameters to come to the applicant. If this set of parameters was not bundled with the registration software, it may be received through an on-line connection with a server.

Legal notices and contract formation

The applicant registration software execution offers an opportunity for bringing legal notices to the attention of the applicant and/or requesting agreement to be bound by the terms of a contract. For contract formation formalities, the completion of the SAKEM procedure where the applicant manipulates an identification token according to instructions displayed on a computer screen may be a clear manifestation of intent.

Variants of the PEKE cryptosystem protocol

According to the original PEKE cryptosystem specifications, the registration software should receive an "initiator message" from the issuer. Actually, the contents of this message may come from diverse sources. It is only when very powerful attackers are suspected that the PEKE specification should be followed exactly. Here are the options:

1. If it is otherwise required to have an on-line connection with the issuer as soon as the registration software is started, it should be easy to have the issuer generate the initiator message as specified.
   
   
2. If the software is connected with a third party, e.g. an Internet service provider, it may be wise to have this third party generate the initiator message.
   
   
3. Otherwise, the registration software executes off-line (more precisely in a store-and-forward way) and the contents of the PEKE initiator message may be generated locally.

Private random source design

A very different system design issue for the registration software operation is the private random source essential to the secret key generatation. There is no easy solution for a reliable private random source on a general-purpose computer: these machines are built to produce deterministic and reproducible results. The challenge arises from the lack of a source of unpredictable bits of sufficient bandwidth, considering the fact that a hacker may try millions of possible outcomes in a very short period of time. In cryptographic applications, any design oversight in this area can lead to significant security weaknesses, as was unforgivingly experienced in the case of an early implementation of Netscape's SSL.

    Outline / Operational / Security / Cryptography / Programming

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

The pass query might be omitted

The pass query is meant to later reassure the applicant that the person he is speaking with is an authorized issuer agent. If there is little room for doubt, the pass query may be omitted from the SAKEM procedure (e.g. if the applicant visits a branch of the issuer for the conversational portion of the SAKEM procedure).

The pass phrases may be computer-generated

The pass query, if any, and the pass reply may be chosen by the registration program instead of the applicant. This would reduce the amount of keyboard usage for the applicant, but may lead to meaningless pass phrases that are harder to remember. It is common to see computer generated passwords made of a few unrelated english language words concatenated with ponctuation marks (a compressed english words listing is needed in the generating program). Obviously, randomness and secrecy should surround the computer generation of pass phrases.

    Outline / Operational / Security / Cryptography / Programming

The secret key is loaded in the identification token.

The key loading operation is where the long-term security of the identification token is obtained. An application designer should consider the security model appropriate to the application. By itself, the secret key of an identification token is a single factor of security. Other factors may be put in the chain of prerequisites for the routine usage of the secret key:

1. A conventional PIN (Personal Identification Number), that is a secret PIN known by the applicant, stored in the issuer database, and chosen by the applicant (e.g. when he runs the registration software);
   
   
2. A token PIN, that is a PIN required to unlock the interface of the identification token (often used with smartcards);
   
   
3. A private applicant's PIN, that is a PIN stored neither in the issuer's database nor in the token, but nonetheless essential to the unlocking of the very secret key generated in this instance of the SAKEM procedure;
   
   
4. A secret key component stored on a computer disk, in a split-key storage scheme.

Various information security techniques are implied by these alternatives. Once a decision is made on the combination suitable for an application, the registration program should be adapted accordingly. For instance, if a token PIN is needed for to load the secret key, the registration program may either accept the PIN from the applicant or instruct him to type the PIN on an attached smartcard reader.

    Outline / Operational / Security / Cryptography / Programming

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

Cryptographic protection applied to the registration request

The term "hybrid" is applied to the frequent dual use of 1) a public key cryptosystem, and 2) conventional cryptographic algorithms for encryption and MAC'ing (Message Authentication Code). The foremost conventional algorithms are respectively DES (or triple-DES) for encryption, and the CBC-MAC construct for MAC'ing (this construct using DES as the base algorithm). The SAKEM procedure is an hybrid cryptographic application.

About the public key cryptosystem side of the story, many details are dependent on the PEKE public key cryptosystem. Adjustments would be needed if the actual public key cryptosystem used was changed to one of the PEKE alternatives.

About the conventional cryptographic algorithms, it is reasonable to use the foremost solutions indicated above. Nonetheless, there may be situations where other encryption and MAC'ing algorithms are preferred.

Contens of the registration request

The message containing the registration request includes the encrypted pass reply that is critical to the bound between the applicant and the generated secret key. It may also contain other encrypted registration data. There is room for enhancements to the basic SAKEM procedure because this data is cryptographically bound to the verification of applicant's identity. For instance, a secret PIN (Personal Identification Number) may be selected by the user at this time. Also, if the registration program can read a serial number in the token where a secret key is loaded, this may further the security of the whole identification scheme.

Data transmission to the issuer's data processing center

Any data transmission means may be used to send the (encrypted) registration request to the issuer's data processing center. The SAKEM procedure is designed so that a voice connection and a data connection are not required simultanously.

    Outline / Operational / Security / Cryptography / Programming

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

Responsiveness in processing registration requests

For faster responses in the processing of registration requests, the receipt of each request should automatically trigger the decryption and filing of the registration request, but at the same time security shouldn't be compromised. For instance, the automatic decryption may be defered while the computer room surveillance is not in effect.

Computer system architecture

It is usually thought that the computer systems best suited to networking with outside applicants and to public key cryptography processing are high end servers like PC, workstations, or departmental systems. The issuer secure database is often on central computers. If these two generalizations apply in a given case, the registration request processing would be done on a server and the database would be on a central computer. A cryptographically protected upload mechanism would thus be needed.

    Outline / Operational / Security / Cryptography / Programming

Conversational portion of the SAKEM procedure

A voice contact is established between applicant and issuer agent.

Once filed in the issuer's database, workflow automation may be applied to registration requests. The task of verifying the applicant's identity may be undertaken:

1. by an issuer agent who is directed to call the applicant, if the applicant may be reached at that occasion,
   
   
2. by an issuer agent in (e.g. a call center operator) who answers a telephone call from the applicant, or
   
   
3. by an issuer agent at a branch location when the applicant shows up.

    Outline / Operational / Security / Cryptography / Programming

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

The main design option is the omitting of the pass query, which may be justified if the applicant has to visit a branch of the issuer to go through the conversational portion of the SAKEM procedure.

    Outline / Operational / Security / Cryptography / Programming

The issuer agent verifies the identity of the applicant.

How does the issuer get personal identification data that is relevant for this verification of identity? Here are three possibilities:

1. The issuer has done business with the applicant before and has his profile (and maybe an historic transaction record) available in the database. This is typical when electronic transaction services are offered to an existing client base.
   
   
2. In the course of the registration program execution, the applicant was asked to provide some references from which the issuer may obtain information. For instance, "up to 3 financial institutions where the applicant was banking, going back up to 5 years ago." The issuer asks these trade references to provide relevant personal identification data before undertaking the conversational portion of the SAKEM procedure.
   
   
3. During the conversation between the applicant and the issuer agent, the applicant is asked to provide the name of referees that are trusted by the issuer, and some facts that can be verified with each referee. The facts suggested by the applicant are noted or recorded. Afterwards, the issuer checks these facts with the referees. This postpones the final acceptance of the registration, but may be attractive for demanding security requirements if the applicant is previously unrelated to the issuer.
   
   A similar scheme for identity verification is in use for (paper-based) passport issuance in Canada: the passport office has a list of trusted individals (actually all the members of a list of professional associations plus police officers and the like) and the passport application form must be countersigned by two referees that personally know the applicant.

    Outline / Operational / Security / Cryptography / Programming

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

It is possible to supplement the SAKEM procedure with a paper-based follow-up procedure, or to limit the value of electronic transactions for an initial trial period (e.g. until the first periodic bill has been paid or the first monthly statement has been received).

    Outline / Operational / Security / 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