Previous Table of Contents Next


C-SET

C-SET (http://www.c-set.com) stands for chip secure electronic transaction. It is the adaptation of SET to French law and its views of individual privacy. Essentially C-SET injects the French government into the SET architecture via government-controlled smart cards and smart card readers, government-issued identities and “translators” that map between C-SET and SET. The C-SET translators serve as combined French taxation authority and firewall on the Internet. Unlike SET, all encryption keys in C-SET are escrowed; that is, they were held by the government, “to avoid any encryption technique falling into the hands of customers.” The French view is that guaranteeing individual privacy is the responsibility of the state.

The C-SET effort is led by Groupement des Cartes Bancaires, a French bank card association and the issuer of the Cartes Bancaires (CB) payment smart card.

The C-SET protocol is essentially identical to the SET protocol except that all transactions must go through gateways controlled by Cartes Bancaires banks, since only they have the keys needed to decrypt the messages generated by C-SET smart cards and C-SETclient software. Figure 7.4 shows how a C-SET cardholder accesses a SET merchant. Notice that the SET payment instruction must go through a Bancaires bank to get to the SET gateway.


Figure 7.4.  C-SET architecture.

The strength of C-SET is that it highlights the unique role smart cards and smart card readers can play in securing electronic commerce and establishing network identity. A smart card token adds a second factor—something you have in addition to the first factor, which is something you know such as a PIN or a password—to a network security architecture and is a convenient and reassuring form in which to create and store a private key. A smart card reader can check a PIN without exposing it to rogue software that might be hiding in publicly accessible and unguarded fields of computer memory.

IATA 791/20.204

While it isn’t a payment system, the IATA 791/20.204 smart card API is included in the EMV’96 section because it conforms to the EMV’96 specification and shows how EMV can be adapted to application domains besides payment systems.

The IATA smart card is used by the airline industry to support Interline Electronic Ticketing (IET). Besides holding passenger information such as name, gender, and language preference, the IATA smart card holds a collection of digitally signed electronic airline tickets. As the tickets are used for passage, they are invalidated and boarding information is placed on the smart card.

IATA 719/20.204 uses the SELECT, GET PROCESSING OPTIONS, and READ RECORD commands of EMV’96 and adds its own WRITE RECORD command in order to write the boarding data to the card.

Cryptographic Smart Cards

The only safe place to store your private key is on something you can take with you and that won’t reveal it under any circumstances. Portability means there is only one copy of your private key. If it is in something you can pop in your pocket, you can make it difficult to get the key out (tamper resistant) and it would be obvious if somebody tried to take it from you (tamper evident). A smart card is a leading candidate for private key storage.

Since the key isn’t coming out of its storage place, all the operations you want to perform with it must be performed inside the card. Thus, the functionality on the card simply replaces low-level functionality in existing cryptographic packages. Rather than performing the processing in a software routine on the host, the routine is moved to the cryptographic smart card and the data shipped to the card for processing when the routine is called by higher-level routines. This is exactly the tack taken to integrate smart cards containing private keys to the Microsoft cryptographic application programming interface (CAPI) and the RSA PKCS #11 Cryptoki application programming interface. The cryptographic application using these APIs can’t tell if the cryptographic functions are being performed on the host computer or in a smart card, thus there is no direct connection between the application and an API for the smart card, per se.

Cryptographic Smart Card Commands

There are a number of cryptographic smart cards on the market which can be seamlessly connected to higher level interfaces, as discussed above, but which also sport their own application programming interfaces. The Schlumberger Cryptoflex card, the Gemplus GPK2000 and GPK4000 cards, the Datakey SignaSure cards, and the Giesecke & Devrient STARCOS family of smart cards are examples of cryptographic smart cards.

In addition to the usual ISO 7816 commands, such as SELECT FILE and READ RECORD, these cards also support commands specific to their cryptographic use. The Giesecke & Devrient STARCOS cards, for example, include the following commands:

  CRYPT
  EXCHANGE CHALLENGE
  KEY STATUS
  COMPUTE SIGNATURE
  VERIFY SIGNATURE
  PUT HASH
  SET HASH
  COMPUTE HASH
  MANAGE SECURITY ENVIRONMENT
  ASYMETRIC INTERNAL AUTHENTICATE

The Schlumberger Cryptoflex cards include the following cryptographic commands, which also appear on the PC/SC SSP API for Cryptoflex:

  RSA INTERNAL AUTHENTICATE
  FULL DES INTERNAL AUTHENTICATION
  LOAD CERTIFICATE
  VERIFY PUBLIC KEY
  VERIFY DATA
  KEY GENERATION
  UPDATE KEY ENCIPHERED

The DCE Personal Security Module API

The primary use of the DCE Personal Security Module (PSM) is to enable public key sign-on to DCE-enabled systems. Public key sign-on is more secure than the traditional password sign-on because it is two-factor (what you know and what you have) and because private keys are harder to guess than passwords. They are also less likely to be written down on a note and stuck on the computer, if only because there is little you can do with a written private key.

Open Group RFC 68 defines an API to the DCE PSM, which consists of the following functions:

  OPEN
  CLOSE
  SIGN_DATA
  VERIFY_DATA
  ENCRYPT_DATA
  DECRYPT_DATA
  PUT_PUB_KEY
  UPDATE_PUB_KEY
  UPDATE_PASSWD

These functions on the PSM are accessed by functions on the DCE Security Login API.


Previous Table of Contents Next