reference manual - error.li · evolution of the document version date principal changes 1.1 oct....

GPK

Reference Manual

Version 3.0

GEMPLUS August 2000

Specific Warning Notice

All information herein is either public information or is the property of and owned solely by Gemplus who shall have and keep the sole right to file patent applications or any other kind of intellectual property protection in connection with such information.Nothing herein shall be construed as implying or granting to you any rights, by license, grant or otherwise, under any intellectual and/or industrial property rights of or concerning any of Gemplus’ information.This document can be used for informational, non-commercial, internal and personal use only provided that:

− the copyright notice below, the confidentiality and proprietary legend and this full warning notice appear in all copies.

− this document shall not be posted on any network computer or broadcast in any media and no modification of any part of this document shall be made.

Use for any other purpose is expressly prohibited and may result in severe civil and criminal liabilities.

The information contained in this document is provided « AS IS » without any warranty of any kind. Unless otherwise expressly agreed in writing, Gemplus makes no warranty as to the value or accuracy of information contained herein. The document could include technical inaccuracies or typographical errors. Changes are periodically added to the information herein. Furthermore, Gemplus reserves the right to make any change or improvement in the specifications data, information, and the like described herein, at any time.

GEMPLUS HEREBY DISCLAIMS ALL WARRANTIES AND CONDITIONS WITH REGARD TO THE INFOR-MATION CONTAINED HEREIN, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY, FIT-NESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT. IN NO EVENT SHALL GEMPLUS BE LIABLE, WHETHER IN CONTRACT, TORT OR OTHERWISE, FOR ANY INDIRECT, SPECIAL OR CONSE-QUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER INCLUDING BUT NOT LIMITED TO DAMAGES RESULTING FROM LOSS OF USE, DATA, PROFITS, REVENUES, OR CUSTOMERS, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF INFORMATION CONTAINED IN THIS DOCUMENT.

GEMPLUS DOES NOT AND SHALL NOT WARRANT THAT THIS PRODUCT WILL BE RESISTANT TO ALL POSSIBLE ATTACKS AND SHALL NOT INCUR, AND DISCLAIMS, ANY LIABILITY IN THIS RESPECT. EVEN IF EACH PRODUCT IS COMPLIANT WITH CURRENT SECURITY STANDARDS IN FORCE ON THE DATE OF THEIR DESIGN, SECURITY MECHANISMS' RESISTANCE NECESSARILY EVOLVES ACCORDING TO THE STATE OF THE ART IN SECURITY AND NOTABLY UNDER THE EMERGENCE OF NEW ATTACKS. UNDER NO CIRCUMSTANCES, SHALL GEMPLUS BE HELD LIABLE FOR ANY THIRD PARTY ACTIONS AND IN PARTICULAR IN CASE OF ANY SUCCESSFUL ATTACK AGAINST SYSTEMS OR EQUIPMENT INCORPORATING GEMPLUS PRODUCTS. GEMPLUS DISCLAIMS ANY LIABILITY WITH RESPECT TO SECURITY FOR DIRECT, INDIRECT, INCIDENTAL OR CONSEQUENTIAL DAMAGES THAT RESULT FROM ANY USE OF ITS PRODUCTS. IT IS FURTHER STRESSED THAT INDEPENDENT TESTING AND VERIFICATION BY THE PERSON USING THE PRODUCT IS PARTICULARLY ENCOURAGED, ESPECIALLY IN ANY APPLICATION IN WHICH DEFECTIVE, INCORRECT OR INSECURE FUNCTIONING COULD RESULT IN DAMAGE TO PERSONS OR PROPERTY, DENIAL OF SERVICE OR LOSS OF PRIVACY.

© Copyright Gemplus, 1997 - 2000.Smart Cards and Smart Card Readers are patent protected by Innovatronand Bull CP8 and are produced by Gemplus under license.MS-DOS® and Windows® are registered trademarks of Microsoft Corporation.

Printed in France.GEMPLUS, B.P. 100, 13881 GEMENOS CEDEX, FRANCE.Tel: +33 (0)4.42.36.50.00 Fax: +33 (0)4.42.36.50.90

Document Reference: DPD05030C0

Evolution of the Document

Version Date Principal Changes

1.1 Oct. 1997 Addition of new features and bug fixes

1.2 June 1998 Addition of new features and bug fixes

2.0 May 1999 Integration of new features (onboard and unwrap)

2.1 Aug. 1999 Integration of comments from version 2.0

2.2 October 1999

Cosmetic improvements, addition of index, some bug fixes. Revised “Terminology” section

3.0 Aug. 2000 Updated to include GPK 16000. Document reformatted.

Contents

PREFACE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IX

Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ixConventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix

Bit Numbering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xRFU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .x3DES_16 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xMathematical Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .x

For More Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xContact Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi

CHAPTER 1: OVERVIEW. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Range Presentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1Data Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2Command Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2Data Access Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2Electronic Purse Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3Public Key Cryptography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3Custom Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3Legal Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4Note on DSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4

CHAPTER 2: GPK FILES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Master File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5Dedicated Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6

File Descriptor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6Elementary Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11

File Descriptor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11File Body Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15

© GEMPLUS 2000

ii Contents

EF Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19

CHAPTER 3: INITIAL STATUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Shipment Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37Initialization Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37Initial File Structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38Master File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39EFKey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39DFSystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40EFCard File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40

Card Serial Number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41Gemplus Issuer Reference Number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41

EFIssuer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42EFMaxSessionKey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42EFSystem. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43Personalization Flag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43IO Buffer Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43EEPROM Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44Lock Byte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44

CHAPTER 4: ACCESS CONDITIONS. . . . . . . . . . . . . . . . . . . . . . . . . 45

General. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45Access Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46Authorization Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49

CHAPTER 5: GPK DES-BASED CRYPTOGRAPHY . . . . . . . . . . . . . . 53

3DES Algorithm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53Key Diversification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54Authentication/Computation of Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . .55Cryptographic Checksum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55GPK 3DES Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57

Cryptographic Security Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58Card/Terminal Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58Secure Messaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59Payment Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61Payment Command Cryptograms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .62

CHAPTER 6: GPK PUBLIC KEY CRYPTOGRAPHY . . . . . . . . . . . . . . 63

Hash Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63SHA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63MD5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64Padding for SHA & MD5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64Padding for RSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65

PK-Algorithms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65RSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65DSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65

GPK Public Keys. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65

© GEMPLUS 2000

Contents iii

Public Key Cryptography Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66Public Key Certification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66Data Deciphering: Unwrapping Using RSA . . . . . . . . . . . . . . . . . . . . . . . . . . . .68

Public Key Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .68PK Internal Authenticate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .68PK Signature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .69

CHAPTER 7: GPK OPTIONAL FEATURES . . . . . . . . . . . . . . . . . . . . 73

Communication Speed. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .73The Switch Speed Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .73The Double Reset Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .74

Communication Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .74Answer To Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .74Custom OS Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .74

CHAPTER 8: ONBOARD KEY GENERATION . . . . . . . . . . . . . . . . . . . 75

Generate RSA Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75Status Byte Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75Retrieving the Public Key Portion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .76Conditions of Use and Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .76Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .76

Key File Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77

CHAPTER 9: THE UNWRAP FEATURE . . . . . . . . . . . . . . . . . . . . . . . 81

Command Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81Status Byte Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81

Retrieving the Decrypted Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82Context Modification After Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82

CHAPTER 10: COMMAND FORMAT . . . . . . . . . . . . . . . . . . . . . . . . . 83

Command Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83Header Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .84Body Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .84Response Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .84

CHAPTER 11: ADMINISTRATION COMMANDS. . . . . . . . . . . . . . . . . . 85

Append Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87Create File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89External Authenticate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93Freeze Access Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96Get Challenge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99Get Info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100Get Response. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103Internal Authenticate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105Read Binary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

© GEMPLUS 2000

iv Contents

Read Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109Select File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111Select File Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114Set Card Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116Set Secret Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117Switch Speed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120Update Binary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123Update Record. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128Verify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130Write Binary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

CHAPTER 12: PAYMENT COMMANDS . . . . . . . . . . . . . . . . . . . . . . 137

Cancel Debit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138Credit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142Debit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145Read Balance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148Select Purse & Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150Set Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153Sign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

CHAPTER 13: PUBLIC KEY CRYPTOGRAPHY COMMANDS . . . . . . . 159

Public Key Cryptography Command Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . .160Create Private Key File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161Erase Card . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162Generate RSA Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163InitHashedData . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166Load Private Key. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167PK_Dir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169PK_Int Auth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170PK_OpenEnvelope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172PK_Send . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174PK_Sign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175PK_Verify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177PutCryptoData . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180SelectCryptoContext . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183

APPENDIX A: THE DEFAULT ANSWER TO RESET 185

APPENDIX B: CARD RETURN CODES 187

APPENDIX C: EXAMPLES OF IMPLEMENTATION OF EMV-COMPATIBLE FEATURE 189

File Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .189Payment System Environment DDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .190Payment System Directory EF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .191

© GEMPLUS 2000

Contents v

Payment System Application Identifiers (AID) . . . . . . . . . . . . . . . . . . . . . . . . .192Application Data Files (ADFs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .192

Implementation in the Terminal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .192Use of the Payment System Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .192Selecting the Application to Be Run . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .192

Examples of Implementation in Cards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .194Single Application Context: E-Purse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .194Multi-Application Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .195

GPK Personalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .196Create DDF and ADF(s) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .196Create FCI Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .196Fill FCI File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .196Create the Payment System Directory EF . . . . . . . . . . . . . . . . . . . . . . . . . . . . .198Fill the Payment System Directory EF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .198

APPENDIX D: APPLICATIVE PK FILE ORGANIZATION 199

APPENDIX E: GPK LIFE CYCLE 201

Blank Chip Phase. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .201Card Initialization Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .201Card Pre-Personalization Phase. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .202Card Personalization Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .202

APPENDIX F: PERSONALIZATION RECOMMENDATIONS FOR PK_CRYPTO APPLICATIONS 203

PK Command Data Inversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .203Incoming Data / Special Data Inversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .203Outgoing Data Special Data Inversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .204

Personalization Scenario Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .205Applicative Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .205

TERMINOLOGY. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209

Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .209Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .212

INDEX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223

List of FiguresFigure 1 - Hierarchy of GPK Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5Figure 2 - DF File Descriptor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6Figure 3 - Structure of FP in Dedicated Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7Figure 4 - Structure of FDB in Dedicated Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8Figure 5 - Status / Options Bytes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9

© GEMPLUS 2000

vi Contents

Figure 6 - Structure of an Option Byte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10Figure 7 - EF File Descriptor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11Figure 8 - Structure of FP in Elementary Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12Figure 9 - Data Referencing in a Transparent File . . . . . . . . . . . . . . . . . . . . . . . . . .15Figure 10 - Data Referencing in a Linear File With Records of Fixed Size . . . . . .16Figure 11 - Data Referencing in a Linear File With Records of Variable Size . . . .16Figure 12 - Purse Files Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19Figure 13 - Format of Extra Word in Enhanced Purse Files . . . . . . . . . . . . . . . . . .21Figure 14 - Structure of a Public Key File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25Figure 15 - Transaction Manager File Structure . . . . . . . . . . . . . . . . . . . . . . . . . . .32Figure 16 - Secret Codes Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33Figure 17 - Secret Code Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33Figure 18 - Unblock Code Reference Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34Figure 19 - Storing of a Secret Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34Figure 20 - IADF Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35Figure 21 - Initial File Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38Figure 22 - Card Serial Number Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41Figure 23 - Lock Byte Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44Figure 24 - Coding of Group Access Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . .48Figure 25 - Coding of AC Secret Code Reference . . . . . . . . . . . . . . . . . . . . . . . . . . .49Figure 26 - Triple DES Implementation in EDE Mode . . . . . . . . . . . . . . . . . . . . . .53Figure 27 - Inverse Triple DES Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . .54Figure 28 - Temporary Diversified 3DES Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54Figure 29 - Certificate Computation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55Figure 30 - CRYCKS Computation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55Figure 31 - Zero - Padding Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56Figure 32 - Secure Messaging Command when Sending Data . . . . . . . . . . . . . . . . .59Figure 33 - Secure Messaging Response when Sending Data . . . . . . . . . . . . . . . . . .60Figure 34 - Secure Messaging Command when Retrieving Data Only . . . . . . . . . .60Figure 35 - Secure Messaging Response when Retrieving Data Only . . . . . . . . . . .60Figure 36 - SHA Algorithm Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63Figure 37 - MD5 Algorithm Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64Figure 38 - Public Key Certification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67Figure 39 - PK Internal Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .69Figure 40 - External Authenticate Command Processing . . . . . . . . . . . . . . . . . . . .94Figure 41 - Internal Authenticate Command Processing . . . . . . . . . . . . . . . . . . . .106Figure 42 - CEGT Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .121Figure 43 - Cancel Debit Command Processing . . . . . . . . . . . . . . . . . . . . . . . . . . .140Figure 44 - Cancel Debit Command Processing (Replacement Debit Requested) 141Figure 45 - Credit Command Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .143Figure 46 - Debit Command Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .146Figure 47 - Read Balance Command Processing . . . . . . . . . . . . . . . . . . . . . . . . . . .149Figure 48 - Select Purse & Key Command Processing . . . . . . . . . . . . . . . . . . . . . .152Figure 49 - Sign Command Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .156Figure 50 - How to use Cryptographic Commands . . . . . . . . . . . . . . . . . . . . . . . . .160Figure 51 - Generate RSA Key Command Processing . . . . . . . . . . . . . . . . . . . . . .165Figure 52 - PK_Int Auth Command Processing . . . . . . . . . . . . . . . . . . . . . . . . . . .171Figure 53 - PK_OpenEnvelope Command Processing . . . . . . . . . . . . . . . . . . . . . .173Figure 54 - PK_Sign Command Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .176Figure 55 - PK_Verify Command Processing in Verify Mode . . . . . . . . . . . . . . . .179Figure 56 - PK_Verify Command Processing in Verify Certificate Mode . . . . . .179Figure 57 - File Structure For Payment Systems . . . . . . . . . . . . . . . . . . . . . . . . . . .189

© GEMPLUS 2000

Contents vii

Figure 58 - GPK Card Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .190Figure 59 - Selecting an Application Using the Payment System Directory . . . . .193Figure 60 - Files Structure for E-Purse Single Application Context . . . . . . . . . . .194Figure 61 - Files Structure for E-Purse Multi-Application Context . . . . . . . . . . .195Figure 62 - Proposed PK File Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .199Figure 63 - PK File Personalization Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . .205

List of TablesTable 1 - DF File Descriptor - Variable Part . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8Table 2 - Option Byte Values for DFs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10Table 3 - EF FDB Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13Table 4 - EF File Descriptor - Variable Part . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14Table 5 - Key Rights According to Key Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22Table 6 - 3DES Key Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22Table 7 - Key Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23Table 8 - Key Numbers in a Key File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23Table 9 - RSA Public Key Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28Table 10 - DSA Public Key Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29Table 11 - RSA Private Key Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30Table 12 - DSA Private Key Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31Table 13 - Example of PK Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31Table 14 - Available EEPROM Size for the GPK Range . . . . . . . . . . . . . . . . . . . . .44Table 15 - Groups of Access Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47Table 16 - Public Portion for a 1,024-Bit Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77Table 17 - Private Portion for a 1,024-Bit Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . .78Table 18 - Public Portion for a 512-Bit Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .78Table 19 - Private Portion for a 512-Bit Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79Table 20 - Administration Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85Table 21 - Options Byte Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .91Table 22 - Control Byte and the Related Access Conditions . . . . . . . . . . . . . . . . . .97Table 23 - Values of P1 and P2 for the Get Info Command . . . . . . . . . . . . . . . . . .101Table 24 - Product Identification Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .102Table 25 - GPK Command Responses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .103Table 26 - Data Returned by Select File Command . . . . . . . . . . . . . . . . . . . . . . . .104Table 27 - Select File Type, Lc, and File ID Values . . . . . . . . . . . . . . . . . . . . . . . . .112Table 28 - F/D Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .121Table 29 - GPK Baud and Reader Frequencies. . . . . . . . . . . . . . . . . . . . . . . . . . . .121Table 30 - Data Encryption for Update Binary . . . . . . . . . . . . . . . . . . . . . . . . . . . .124Table 31 - Certificate Computation for Update Binary . . . . . . . . . . . . . . . . . . . . .125Table 32 - Lc and Field Values for Update Binary . . . . . . . . . . . . . . . . . . . . . . . . .126Table 33 - Data Encryption for Write Binary . . . . . . . . . . . . . . . . . . . . . . . . . . . . .133Table 34 - Certificate Computation for Write Binary . . . . . . . . . . . . . . . . . . . . . .134Table 35 - Lc and Field Values for Write Binary . . . . . . . . . . . . . . . . . . . . . . . . . .135Table 36 - Payment Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .137Table 37 - Cancel Debit Access Condition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .138Table 38 - Debit Access Condition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .145Table 39 - Public Key Cryptography Commands . . . . . . . . . . . . . . . . . . . . . . . . . .159Table 40 - Operation Modes for SelectCryptoContext Command . . . . . . . . . . . .183Table 41 - Answer To Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .186Table 42 - ADF Entry Encapsulation, to be applied to each ADF . . . . . . . . . . . . .191

© GEMPLUS 2000

viii Contents

911

Table 43 - ADF Entry TLV’s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1Table 44 - Application Priority Byte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19

© GEMPLUS 2000

Preface

tem

13

This manual provides reference information about the GPK range of cards. It provides detailed descriptions of the following:

• The card memory structure and functions

• How the card protects data

• How to protect and verify transmissions with the card

• How to send low-level commands to the card

AudienceThis manual enables you to do the following:

• Understand how the operating system works

• Access reference information about the operating system

• Develop low-level applications for GPK cards using their own card interface sys

The manual assumes that you are familiar with the following subjects:

• Cryptography

• Smart card technology

ConventionsThe following conventions are used throughout this document.

• By default, a numeric value is expressed in decimal notation.

• Whenever a value is expressed in binary, it is followed by the “b” character. Forexample the decimal value 13 expressed in binary becomes 1101b.

• The h character follows a hexadecimal number. For example the decimal value expressed in hexadecimal becomes 0Dh.

© GEMPLUS 2000

x Preface

sh

Bit NumberingA byte B consists of 8 bits b7b6b5b4b3b2b1b0: b7 is the most significant bit and b0 the least significant bit:

A string of bytes consists of n concatenated bytes Bn-1Bn-2....B1B0: Bn-1 is the most significant byte and B0 the least significant byte:

RFUReserved for Future Use (RFU). When RFU bytes are included in a command, the value 0 (or 00h) should be used.

3DES_16This notation is used to indicate that 3DES is being used to diversify a 16-byte 3DES key, and not simply running its value through the 3DES algorithm. This would therefore be shown as:SK = 3DES_16(data, K)

Thus, 3DES_16 gives a result of 16 bytes, while 3DES gives a result of 8 bytes.

For further details on key diversification, see “Key Diversification” on page 54.

Mathematical Notation⊕XOR operation

For More InformationYou should also have access to the following documentation:

• ISO 7816-3—Identification Cards, Part 3: Electronic Signals and Transmission Protocols

• ISO 7816-4— Identification Cards, Part 4: Inter-Industry Commands for Interchange

• EMV—IC Card Specifications for Payment Systems, Parts 1, 2, 3

• ISO / IEC 9796—2 Information Technology—Security Techniques—Digital Signature Schemes Giving Message Recovery, Part 2: Mechanisms Using a HaFunction.

• ISO / IEC 9797—Information Technology—Security Techniques—Data Integrity Mechanism Using a Cryptographic Check Function Employing a Block Cipher Algorithm

• ANSI X9.31—Digital Signature Using Reversible Public Key Cryptography for theFinancial Services Industry

One Byte E� E� E� E� E� E� E� E�

A string of n bytes %Q�� %Q�� ² ² %� %� %� %�

© GEMPLUS 2000

Preface xi

Contact DetailsWe welcome your feedback to help us provide high-quality documentation. Contact us at:

Please quote the document reference, your job function, and your company.

E-mail [email protected]

Postal Technical & Online Documentation (TOLD)GemplusB.P. 10013881 Gémenos CedexFRANCE

© GEMPLUS 2000

© GEMPLUS 2000

1
Overview
rom

d for

Range PresentationThe multi-application Gemplus Public Key (GPK) is an operating system adapted to multi-purpose and payment applications.

This GPK operating system has been implemented on several chips to benefit from a range of EEPROM sizes. The GPK range consists of the GPK8000 (approximately 8KB EEPROM available), and GPK16000 (approximately 16KB EEPROM available).

GPK includes:

• ISO 7816-4 compatible data structures, commands, and return codes

• A complementary set of Gemplus-proprietary administrative commands, taken fMPCOS-EMV

• Payment functions, data structure and commands, taken from MPCOS-EMV, including the electronic purse function

• EMV-compatibility features

• The 3DES algorithm used for secure messaging compliant with ISO 7816-4, anciphering and deciphering

• SSL 1,024-bit RSA signature

• RSA (up to 1,024 bits) signature/decryption, normal mode and CRT mode

• RSA (up to 1,024 bits) verification/encryption

• DSA signature and verification (see “Note on DSA” on page 4)

• RSA onboard key generation (512 and 1,024 bits)

• SHA-1 for hashing

• MD5 for hashing

• Random generation (8 bytes and 32 bytes)

• Padding with PKCS#1 version 1.5, ISO9796-2, ANSI X9.31

2 Overview

red in eight ss

n an

) and

GPK

cords

re.

Data StructureGPK is based on specific file structures. File are organized into a two-level hierarchy. The Master File (MF) is the top level of the hierarchy. The MF can have Elementary Files (EFs) and Dedicated Files (DFs) beneath it. DFs hold groups of EFs, and EFs hold data (see “Figure 1 - Hierarchy of GPK Files” on page 5).

Command SetThe GPK operating system includes the following:

• Administration commands, such as creating files, writing, reading from files.

• Public Key Cryptographic commands, dedicated to public key algorithms (RSA, DSA – see “Note on DSA” on page 4).

• Payment commands, such as crediting a purse, debiting a purse.

Data Access ManagementAccess to GPK card files can be secured by secret codes. The secret codes are stoEFs that are called secret code Elementary Files (EFsc). Each EFsc can store up tosecret codes, numbered from 0 to 7. The MF and each DF can hold one EFsc. Acceconditions define the level of protection granted to a file (such as read or write, for example).

The card determines if access to a file should be allowed by comparing the values iauthorization register to those required by the access condition.

Access conditions are stored in DF and EF file descriptors. They contain two parts:

• A group AC that determines the level of protection. Each type of access (see “Access Conditions” on page 46) can be protected by up to two secret codes. This part also contains information about the cryptographic key used to generate session keys for all secure messaging with the file. This information is the level (global or local) and SFI for the key file.

• An AC Secret Code Reference that specifies the secret code file (global or localthe secret code number(s).

Secure messaging is a cryptographic process that secures data transmissions with cards.

The presentation of secret codes can be imposed prior to selecting a file. The card rethe successfully submitted secret code numbers in an authorization register.

Electronic Purse ArchitectureGemplus has issued a document called Electronic Purse Architecture for MPCOS-EMV. This document describes the minimum requirements to build a secure purse structu

Note: Secure messaging is not an access condition.

© GEMPLUS 2000

Overview 3

ns. ret ps”

n.

SecurityGPK includes a series of commands that implement cryptographic functions to form a complete application security scheme: authentication, calculation of the temporary key, certificate generation, signatures, secure messaging.

A temporary key is a cryptographic key that GPK cards use for cryptographic processing. Once a temporary key has been generated, cryptographic security features can be used. These are:

• Verification of administration command transmission using secure messaging.

• Payment dedicated security using cryptographic certificates.

Public Key CryptographyGPK includes a series of commands that implement public key cryptographic functioThese are used to manage signature, verification and the “wrapping” of keys. A secsession key is wrapped using a public key algorithm and sent. The recipient “unwrathe key using the same public key algorithm.

CommunicationGPK cards send and receive data under the T = 0 communication protocol format according to the ISO 7816-3 standard.

In addition, GPK has high-speed fast input/output routines that can be activated by aSwitch Speed command.

Custom ConfigurationsThe GPK card is adapted to multi-purpose and payment applications and can be configured to suit your needs. Contact your sales representative for more informatio

© GEMPLUS 2000

4 Overview

d the

s

is

his

er.

Legal RestrictionsIn order to comply with legal restrictions on exporting cryptography products, Gemplus has defined three product options. These options relate to the “unwrap” function anlengths of keys that can be used with this function.

The three options are:

• -INTL: The unwrap function supports RSA keys with lengths of up to 56 bits. Thioption can be exported from France with no restrictions.

• -STD: The unwrap function supports RSA keys with lengths of up to 512 bits. Thoption can be exported from France with no restrictions.

• -FULL: The unwrap function supports RSA keys with lengths of up to 1,024 bits. Toption is subject to individual export licenses.

Note on DSAThe DSA algorithm is not included as standard. However, it is feasible and can be implemented on demand.

Note: The required option must be specified by the customer when placing the ord

© GEMPLUS 2000

© GEMPLUS 2000

2
GPK Files
The files in GPK cards are organized in a two-level hierarchy.

The level formed by the Master File (MF) with Elementary Files (EF)s directly beneath it is called the global level. The level formed by Dedicated Files (DF)s with EFs beneath them is called the local level.

The following figure shows the structure of the GPK file hierarchy:

Figure 1 - Hierarchy of GPK Files

Master FileThe MF is the root of the GPK file structure. It defines level zero in the card and may contain both Dedicated Files (DFs) and Elementary Files (EFs). It is the equivalent of the DOS root directory. The MF (only one per card) can contain up to 63 EFs and DFs. The MF is actually a DF itself.

MasterFile

Elementary File

Elementary File

Elementary File

Elementary File

DedicatedFile

DedicatedFile

Global Level

Local Level

6 GPK Files

Dedicated FilesDFs store sets of EFs. In GPK cards, each DF stores the set of EFs that form an application. DFs are the equivalent of DOS directories. Each DF can store up to 63 EFs, but no nested DFs are allowed.

All GPK DFs consist of a system header, known as a descriptor and a body. The descriptor stores the information needed by the GPK operating system to manage files. The body is a block of data that immediately follows the descriptor. The DF name stored in the descriptor is part of the attributes.

File DescriptorWhen you create a file, the Create File command generates the file descriptor. The following diagram shows the structure and contents of the file descriptor for DFs.

Figure 2 - DF File Descriptor

Variable Attributes

File Identifier

Group 1 Group 2 RFUT/L

AC Secret Code Reference

Status Options RFUT/L

Status / Options

DF NameT/L

Fixed Part:

Variable Part:

Fn CksLng AttrSize H Size LFp

FDBGroup 1

ACGroup 2

ACRFU

© GEMPLUS 2000

GPK Files 7

The fields in the file descriptor are as follows:

Field Length Description

Fp 1 byte File Pedigree. This byte is used by the operating system (OS) to locate a file within the hierarchy. It specifies the descriptor type (1 = DF) in bit F, the level (0 = MF and 1 = DF) in bit L and the sequential number of its parent (that is, the MF):

Figure 3 - Structure of FP in Dedicated Files

Fn 1 byte File Number. This is the sequential creation number of a file. Coded on six bits, it allows the creation of up to 63 DFs (value 00h is not allowed).

Note: The Fp-Fn pair is unique throughout the memory and is used by the OS to search for a given file.

Size H/L 2 bytes Indicates the size of the data entity. For DFs, they are always zero.

Lng Attr 1 byte Indicates the length of the variable attributes (in bytes).

CKS 1 byte Checksum. This integrity byte is used to check whether system data has been corrupted in the entity. The integrity byte is calculated on the data making up the descriptor (not including the CKS byte itself). It is calculated by performing successive XOR operations on each byte and a final XOR operation between the result and the value A5h.

CKS = {( Fp ⊕ Fn ⊕ Size ⊕ LngAttr ⊕ Variable Attributes) ⊕ A5h}

so that ∑⊕ (file descriptor ) = 0 proves the integrity of the header.

∑⊕ is the total of the XOR operations.

Bit 7 6 5 4 3 2 1 0

Parent FnF L

© GEMPLUS 2000

8 GPK Files

Variable Attributes

Fixed Part

Variable Part

The variable part of the attribute manipulated by the OS is structured in a proprietary compact TLV format.

The tag is coded on three bits allowing eight different objects to be referenced.

The length is coded on five bits allowing objects to be sized from 1 to 31 bytes. The objects possible for DFs are:

The other values are either Reserved for Future Use (RFU) or are valid for EFs only.

FDB 1 byte File Descriptor Byte. This byte takes the following format:

Figure 4 - Structure of FDB in Dedicated Files

Note: When a DF is created, the FDB must be set to the above value (38h), otherwise the command is rejected.

File Identifier

2 bytes This is allocated when the file is created. The Short File Identifier (SFI) corresponds to the five least significant bits (lsb) of the file identifier.

Group 1, 2 AC

1 byte each These bytes define the level of protection applicable for each group of commands for that particular file. See Table 15, “Groups of Access Conditions,” on page 47 for details on access conditions.

Tag Length Object description

000 3 AC Secret Code Reference (Group 1, Group 2, RFU)

001 3 Status and Options bytes.

011 1 to 16 DF name

Table 1 - DF File Descriptor - Variable Part

Bit 7 6 5 4 3 2 1 0

0 0 1 1 1 0 0 0

© GEMPLUS 2000

GPK Files 9

Where:

Tag 000 1 byte each AC Secret Code Reference. These bytes give the number of the secret code in the secret code file and the level (MF or DF) of the file for a maximum of two secret codes. The access condition attached to a command must be satisfied before executing the requested action. The first byte (most significant) is Group 1, the second is Group 2 and the final byte (least significant) is RFU. Please refer to Table 15, “Groups of Access Conditions,” on page 47 for further information.

Tag 001 3 bytes Status / Options bytes

Figure 5 - Status / Options Bytes

Status 1 byte The status byte may be used to memorize particular events related to the DF life such as its invalidation. 00h means DF is valid; 01h means DF has been invalidated.

Note: The OS does not provide any command for invalidating a DF. This feature may be added as a filter.

Status OPT RFU

© GEMPLUS 2000

10 GPK Files

OPT 1 byte The Options byte is only used in DFs. The options held in the options byte are taken into account by GPK after the DF selection and remain available until either the next reset or the next DF selection. It has the following structure:

Figure 6 - Structure of an Option Byte

The following table shows the options indicated by each bit:

RFU 1 byte Reserved for future use.

Tag 011 1-16 bytes DF name coded on 1-16 bytes. This field is optional. In order to select unambiguously by DF name, each DF should be uniquely named in the card.

Bit 7 6 5 4 3 2 1 0

CanDeb

RFUCurBal

RFURFURFURFUEA

Table 2 - Option Byte Values for DFs

Bit Value Option Indicated

EA 1 Select Purse & Key and Select File Key commands require external authentication.

0 Select Purse & Key and Select File Key commands do not need an external authentication.

b6-b3 RFU

Cur Bal 1 Current balance can be used to compute sign certificates provided this option is not reversed using Set Options (see “ Set Options” on page 153).

0 Current balance can never be used to compute Sign certificates (see “ Sign” on page 155).

Can Deb 1 Cancel Debit command disabled.

0 Cancel Debit command enabled.

0 RFU

© GEMPLUS 2000

GPK Files 11

ation

iles.

Selection by Partial NameGPK allows selection by partial name. Thus, a DF called “GEMPLUS_EP”, will be selected by the Select command performed with “GEMPLUS” only.

Elementary FilesElementary files are the main component of the GPK file structure. They store applicdata.

All GPK EFs consist of a system header, known as a descriptor and a body. The descriptor stores the information needed by the GPK operating system to manage fThe body of an EF, that immediately follows the descriptor, holds data.

File DescriptorWhen you create a file, the Create File command generates the file descriptor. The following diagram shows the structure and contents of the file descriptor for EFs.

Figure 7 - EF File Descriptor

Caution: If more than one DF satisfies the selection criteria, the Select command selects the DF that was created first. In the above example, if another DFsimply called “GEMPLUS” exists, then running the Select command with “GEMPLUS” as the selection criteria selects the “GEMPLUS” file if “GEMPLUS_EP” was created first

Variable Attributes

Fixed Part:

Variable Part:

Group 1 Group 2 Group 3


RFU RFU RFUT/L

Status / Options

Record LengthT/L

Fp Fn Size H Size L CksLng Attr

File IdentifierFDBGroup 1

ACGroup 2

ACGroup 3

AC

T/L

© GEMPLUS 2000

12 GPK Files

The fields in the file descriptor are as follows:


Fp 1 byte File Pedigree. This byte is used by the OS to locate a file within the hierarchy. It specifies the descriptor type (0 = EF) in bit F, the level (0 = MF (global) and 1 = DF (local)) in bit L and the sequential number of its parent:

Figure 8 - Structure of FP in Elementary Files

Fn 1 byte File Number. This is the sequential creation number of a file. Coded on six bits, it allows the creation of up to 255 EFs (value 00h is not allowed).

Note: The Fp-Fn pair is unique throughout the memory and is used by the OS to search for a given file.

Size H/L 2 bytes For EFs, these indicate the size of the file.

Lng Attr 1 byte Indicates the length of the variable attributes (in bytes).

CKS 1 byte Checksum. This integrity byte is used to check whether system data has been corrupted in the entity. The integrity byte is calculated on the data making up the descriptor (not including the CKS byte itself). It is calculated by performing successive XOR operations on each byte and a final XOR operation between the result and the value A5h.

CKS = {( Fp ⊕ Fn ⊕ Size ⊕ LngAttr ⊕ Variable Attributes) ⊕ A5h}

so that ∑⊕ (file descriptor ) = 0 proves the integrity of the header.

∑⊕ is the total of the XOR operations.

Bit 7 6 5 4 3 2 1 0

Parent FnF L

© GEMPLUS 2000

GPK Files 13

Variable Attributes

Fixed Part

Table 3 - EF FDB Values

FDB 1 byte File Descriptor Byte. This contains information about the type of file (for example, data EF, key EF, purse EF) and about the file structure. This byte takes the following format:

b7 b6 b5 b4 b3 b2 b1 b0 Meaning

0 0 File not shareable.

x x x Type of File

1 0 1 Key EF

1 0 0 Secret Code EF

0 1 1 Purse EF

0 1 0 Transaction Manager EF

0 0 1 Internal Application Data File

0 0 0 EF containing data not interpreted by the card (Data File).

x x x Structure of Data EF

0 0 0 No information recovered.

0 0 1 Transparent

0 1 0 Linear fixed, no further information.

0 1 1 Linear fixed, simple TLV.

1 0 0 Linear variable, no further information.

1 0 1 Linear variable, simple TLV.

1 1 0 Cyclic, no further information.

1 1 1 Cyclic, simple TLV.

The EF types listed in the previous table are described in “EF Types” on page 19. The structures are described in the section, “File Body Structure” on page 15.

Bit b7 is normally set to 0 (GPK does not allow the creation of a file if this bit is set to 1).

© GEMPLUS 2000

14 GPK Files

Variable Part

The variable part of the attribute manipulated by the OS is structured in a proprietary compact TLV format.

The tag is coded on three bits allowing eight different objects to be referenced.

The length is coded on five bits allowing objects to be sized from 1 to 31 bytes. The objects possible for EFs are:

The other values are either Reserved for Future Use (RFU) or are valid for DFs only.

When creating an EF, the OS does not check the contents of the FDB (except for the two msb), so more than one of each type of file can be created. However, some EFs are assumed to be unique in a given DF (for example, the secret code file, IADF). These files are accessed internally by GPK using their FDB, so if more than one of these files is created, only the first one is recognized.

File Identifier

2 bytes This is allocated when the file is created. The Short File Identifier (SFI) corresponds to the five least significant bits (lsb) of the file identifier. It is used to designate a file from within a file operation command such as Read Binary and Update Binary.

Group 1, 2 and 3 AC

1 byte each These bytes define the level of protection applicable for each group of commands for that particular file. See “Table 15 - Groups of Access Conditions” on page 47 for details on access conditions.

Tag Length Object description

000 3 AC Secret Code Reference

001 3 Status and Options bytes. For EFs, the values are zero or RFU.

100 1 Record length

Table 4 - EF File Descriptor - Variable Part

Tag 000 1 byte each AC Secret Code Reference. These bytes give the number of the secret code in the secret code file and the level (MF or DF) of the file for a maximum of two secret codes. The access condition attached to a command must be satisfied before executing the requested action. The first byte (most significant) is Group 1, the second is Group 2 and the final byte (least significant) is Group 3. Please refer to “Table 15 - Groups of Access Conditions” on page 47 for further information.

Tag 001 3 bytes Status / Options bytes. As stated, these are normally set to zero for EFs.

Tag 100 1 byte Record Length. This field contains the record length for cyclic and linear fixed record files only. This byte is not valid for other EFs and is normally set to zero.

© GEMPLUS 2000

GPK Files 15

data

can ive

ng

is four five

File Body StructureThe file body of an elementary file stores data. GPK cards can store up to four different EF structures. They are as follows:

• Transparent files

• Linear fixed files (see “Linear Fixed Files” on page 16)

• Linear variable files (see “Linear Variable Files” on page 16)

• Cyclic elementary files (see “Cyclic Files” on page 17)

These file structures are described in this section.

Transparent FilesFDB value: 00000001b or 01h.

A transparent file consists of an unstructured sequence of bytes, that can be accessed by specifying an offset relative to the start of the EF.

The offset size is given in “data units” which can be 1 byte or 4 bytes. The size of a “unit” is written to the lock byte, using the Set Card Status command (see “ Set Card Status” on page 116), during the personalization stage. The contents of the lock bytebe read by using the Get Info command. The first byte of a transparent EF has the relataddress “00h”.

Data in a transparent file can be addressed using the offset, as shown in the followifigure:

Structured FilesThese consist of the following types:

• Linear fixed files

• Linear variable files

• Cyclic files

Each type is described separately in the following sections. Structured files contain records and each record reserves one byte for system use. For example, if the databytes long for each record, the additional byte reserved by the system brings this tobytes.

Data Unit 4 bytes 1 byte

Offset Offset Byte to be read

0h 0h B1

1h B2

2h B3

3h B4

1h 4h B5

5h B6

Figure 9 - Data Referencing in a Transparent File

© GEMPLUS 2000

16 GPK Files

Linear Fixed Files

FDB value: 00000010b or 02h. - No further information.Or FDB value: 00000011b or 03h. - Simple TLV (Tag Length Value).

A linear fixed file consists of a sequence of individually identifiable records of the same size. The size is determined during file creation and is stored in the file descriptor (see “File Descriptor” on page 11). Records are referenced #1, #2, #3, ... in the order of their creation.

The data is referenced as shown in the following figure:

Figure 10 - Data Referencing in a Linear File With Records of Fixed Size

Where:

SB is a byte reserved by the OS.

Linear Variable FilesFDB value: 00000100b or 04h. - No further information.

Or FDB value: 00000101b or 05h. - Simple TLV.

A linear variable file consists of a sequence of individually identifiable records of variable size. Records are selected in the same way as linear fixed files. The file is handled by the interface as a sequence of independent records.

The data is referenced as shown in the following figure:

Figure 11 - Data Referencing in a Linear File With Records of Variable Size

Where:

SB is a byte reserved by the OS.

Note: Updating a record does not modify the record number.

The number of records assigned to a linear fixed file cannot be higher than 255.

SB Record 1

SB Record 2

SB Record ...

SB Record n

SB Record 1

SB Record 2

SB Record ...

SB Record n

© GEMPLUS 2000

GPK Files 17

Cyclic Files

FDB value: 00000110b or 06h. - No further information.Or FDB value: 00000111b or 07h. - Simple TLV.

A cyclic EF consists of a sequence of records of the same length, used to store information in chronological order. When all the records have been used for storage, then updating a record overwrites the oldest record. The maximum number of records is 254.

The file is handled by the interface as a sequence of independent records.

The record length is indicated during the file creation and stored inside the file descriptor.

The records are referenced #1, #2, #3, in the inverse order of their creation. This means that the last written record (appended or updated) always has the number #1. The current record is always record #1. On selection of a cyclic EF, the current record is #1.

Data in a cyclic file can be referenced as shown in the following example:

1. Append a record with the value “AA”.

2. Append a record with the value “BB”.

3. Append a record with the value “CC”.

Rec # Value

1 AA

Rec # Value

1 BB

2 AA

Rec # Value

1 CC

2 BB

3 AA

© GEMPLUS 2000

18 GPK Files

this

ary to is

t

r the

cord

4. Update a record with the value “ZZ”. The Update Record command can only be used for the current record for cyclic files. It updates the “next” record, which in case is record number 3. The file is now as follows:

5. It is now impossible to perform an Append Record command (even though the file is not yet full). This is because the current record is not the latest created record (record #2 is). To make the latest created record the current record, it is necessperform an Update Record command for each record in the file. Remember that thcould be as many as 254.

To avoid this, use the Append Record command until the file is full, then use the Update Record command to write data.

6. If a further Update Record command is performed (containing a data value of “YY”), the file would look like this:

Rec # Value

2 CC

3 BB

1 ZZ

Rec # Value

3 CC

1 YY

2 ZZ

Note: Remember when calculating the body size of a cyclic file that each record reserves one byte for system use.

The Append Record command does not cycle, that is, after appending the lasrecord of the file, no more Append Record commands are allowed.

Reading the current record always returns the contents of the last appended olast updated record.

Before updating, the current record pointer is incremented, so that the next reis updated and becomes the current record. The Update Record command cycles at the end of the file.

© GEMPLUS 2000

GPK Files 19

EF TypesGPK cards can store up to seven different EF types. They are as follows:

• Purse files (see “Purse Files” on page 19)

• Enhanced purse files (see “Enhanced Purse Files” on page 21)

• 3DES key files (see “3DES Key Files” on page 21)

• Public key files (see “Public Key Files” on page 24)

• Transaction manager files (see “Transaction Manager Files” on page 32)

• Secret code files (see “Secret Code Files” on page 33)

• Internal Application Data Files (see “Internal Application Data File (IADF)” on page 35)

Purse FilesFDB value: 00011001b or 19h.

GPK purse files contain one purse only. Each DF can hold up to 32 purse files and these files must all be among the first 32 files created in a DF.

The terminal addresses purse files by specifying their SFI (see “File Descriptor” on page 11). Purses are structured as follows:

Figure 12 - Purse Files Structure

Offset(in words)

Maximum Balance Credit Key File CrKF

0

Maximum Free Debit Value Access 1

Dbt Rdb

Current (Active) Balance Cks 1 2

Backup Balance Cks 2 3

Terminal Transaction Counter Not Used 4

© GEMPLUS 2000

20 GPK Files

K


Maximum Balance

3 bytes A register that stores the maximum balance that the purse can hold.

Credit Key File 5 bits Specifies the SFI of the file holding the purse credit key. This file must be stored in the same DF as the purse file itself, so the hierarchical level is always local.

Maximum Free Debit

3 bytes Stores the maximum value that can be debited from the purse when the Debit access condition has not been fulfilled. If this value is set to 00h, the Debit access condition must be fulfilled for all debits.

Access Conditions for Dbt and RdB

1 nibble each

Store the Debit and Read Balance access conditions respectively. Access condition values from 1 to 7 specify the secret code number that must be submitted before the purse can be accessed. The access conditions are defined as follows:

0000b No secret code protection.

0xxxb Secret code xxx protected (xxx ≠ 000).

1xxxb Access never allowed.

Current (Active) Balance

3 bytes Stores the current balance value of the purse.

Backup Balance

3 bytes Stores the previous balance of the purse (that is, before the last transaction was carried out). GPK can use this value to restore the purse configuration after any incorrect purse updates.

Checksums Cks1 and Cks2

1 byte each

Checksums of the current and backup registers respectively. They are obtained by performing an XOR operation on the first three bytes of each word and inverting the final result.

Terminal Transaction Counter (TTC)

Stores the TTC’s two MSB while the debit is being processed. This field is used to identify which terminal performed the last debit operation, and is checked by GPbefore any Cancel Debit command can be executed.

© GEMPLUS 2000

GPK Files 21

The

Enhanced Purse FilesFDB value: 00011001b or 19h.

GPK purses can be enhanced to include additional functions. Enhanced purses include an extra word at the Offset 5 position. This can be used to protect the Credit operation with a secret code. It can also be used to specify the hierarchical level of the access conditions for the Read Balance, Debit, and Credit operations, that is, whether the secret codes are to be used from the global EFsc or the local EFsc (see L in the description that follows the next figure).

The extra word has the following format:

Figure 13 - Format of Extra Word in Enhanced Purse Files

The first three bytes are reserved for future use.

3DES Key FilesFDB value: 0101001b or 29h.

If b7 is set to one in the FDB, the FDB value is: A9h. This may be used to flag a special key file called a “Transport Key File”, located under the MF. Such a file cannot be created using the standard Create File command. (See “ Create File” on page 89).

3DES key files store the cryptographic keys used in all GPK cryptographic functions.MF and each DF can store one or more 3DES key files.

Each 3DES key file can store up to four 3DES keys. See “Table 8 - Key Numbers in a Key File” on page 23.

00h 00h 00h 000L CAC


RFU 3 bytes Reserved for future use.

000L 1 nibble L Defines the level of the EFsc file for the Read Balance, Debit, and Credit access conditions:

0 Global (the secret codes are contained in the EFsc of the MF).

1 Local (the secret codes are contained in the EFsc of the currently selected DF).

CAC 1 nibble Credit Access Condition. The access condition is defined as follows:

0000b No secret code protection for Credit operations.

0xxxb Credit operations are protected by secret code number xxx from either the current EFsc of the selected DF or the EFsc of the MF (see L).

1xxxb This purse cannot be credited.

© GEMPLUS 2000

22 GPK Files

nd

ation rent used

tions

ese used

sed

gle ders.

GPK uses different types of cryptographic keys as follows:

• Administration keys used for the computation of temporary administration keys asecure messaging.

• Payment keys used for payment commands such as transaction certificate generand the computation of temporary certification keys. It is recommended that diffepayment keys be assigned to the main payment functions for example, the key for Credit operations will be different from that used for Debit operations.

• Log keys can be used to initiate a payment session (see “ Select Purse & Key” on page 150) but not an administration session (see “ Select File Key” on page 114). However, a session key derived from a log key can be used for administration acsuch as secure messaging.

• Signature keys are payment keys dedicated to the computation of signatures. Thkeys cannot be used to compute temporary certification keys and they cannot beby the Select Purse & Key command.

• Authentication keys used for authentication commands. These keys cannot be uby the Select Purse & Key and Select File Key commands.

Different keys in a given file must be updated separately.

3DES cryptographic keys are stored as two consecutive standard DES keys in a sinkey file. They thus take up 16 bytes plus an additional eight bytes for the two key hea3DES keys are stored in 3DES key files as follows:

Both parts of the 3DES key must be of the same key type.

SelP&K SelFkCredit/Debit Sign

External/Internal

AuthenticationSecure

Messaging

Administration Y Y

Payment Y Y Y

Log Y Y Y Y

Authentication Y

Signature Y Y

Table 5 - Key Rights According to Key Types

Key Type Part 1 00h Kv Cks

K15 K14 K13 K12

K11 K10 K9 K8

Key Type Part 2 00h Kv Cks

K7 K6 K5 K4

K3 K2 K1 K0

Table 6 - 3DES Key Format

© GEMPLUS 2000

GPK Files 23

Where:

Key types are coded on one byte. The possible key types are as follows:

Table 7 - Key Types

The storage of 3DES keys can be illustrated as follows:

3DES keys are stored as two consecutive DES keys. The key numbers are given in the following table.

Table 8 - Key Numbers in a Key File

b7 b6 b5 b4 b3 b2 b1 b0 Key Types

x x x 0 x x 0 0 Administration Key (Secure Messaging)

x x x 0 x x 0 1 Payment Key (Transaction Certificates)

x x x 1 x x x 1 Signature Key

x x x 0 x x 1 0 Log Key

x x x 0 x x 1 1 Authentication Key


Kv 1 byte Key version number. If a terminal updates a key, it can write a key version number to this field. GPK does not manage this field. The default value is 00h.

Cks 1 byte Checksum. It is obtained by performing an XOR operation on the eleven other bytes of the key part and inverting the final result.

K15–K0 1 byte each Store the key values.

Caution: For all applications, it is essential that you block read access to 3DES key files.

Key Key Number

First 0

Second 2

Third 4

Fourth 6

Note: Key numbers must be multiples of 2.

© GEMPLUS 2000

24 GPK Files

Public Key FilesFDB value: 00101100b or 2Ch.

A public key file is a linear variable file (see “Linear Variable Files” on page 16), with a specific FDB (2Ch). Any number of public key files can be created in a DF. The PK crypto commands reference public key files by their SFIs.

In GPK, public key files may contain:

• Up to one public key and one private key made up of key elements

• Certificates, which are the signatures of a set of keys by a Certification Authority(CA)

Both public and private key elements can be either DSA key elements (see “Note on DSA” on page 4) or RSA key elements. DSA key elements have a key length of 512 bits or 1,024 bits, whereas RSA key elements can have a key length of 512, 768 or 1,024 bits. In all cases, the modulus is equal to the key length.

Private keys are used by the card for internal authentication or signature of transactions.

Public keys are used by the terminal for external authentication and the verification of card transactions.

A card certificate is used by a terminal to verify that the public keys in the card have been certified by a CA.

Structure of a Public Key File

Public key files are made up of a public portion (where public keys are stored) and a private portion (where private keys are stored). Each part of the file begins with a file header, followed by a system record, followed by the key elements (one record per element). The public portion of the file is readable and accessible, but the private portion is not accessible (and therefore not readable). Certificates are stored in the public portion of the file.

Note: This is a proprietary format.

© GEMPLUS 2000

GPK Files 25

The following diagram illustrates this structure:

Figure 14 - Structure of a Public Key File

Where:

The System Record (Tag No. 0)

The system record must be the first record in each part of the file, and therefore immediately follows the file header. It is seven bytes long and is structured as follows:

End of Previous file

Public file header

Lsys0 Tag0 System Record Indicates the key type, the key length, access conditions for PK commands and the certification flag.

Lsysi Tagi Public key element A record storing one public key element.

--------------------------

Lsysj Tagj Public key element Final public key element record.

Private file header The private portion is non-accessible.

Lsys0 Tag0 System Record Indicates the same information as for the public portion system record.

Lsysk Tagk Lng || Private key element

A record storing one private key element.

--------------------------

Lsysl Tagl Lng || Private key element

Final private key element record.

Beginning of next file

Lsys0,i,j is one byte reserved by the operating system to store the length of the record (for example, 07h in the case of the system record).

Tagi,j is a tag for a public key element.

Tagk,l is a tag for a private key element.

Lng is the length of the private key element

B6 B5 B4 B3 B2 B1 B0

Tag_Nb Klgth Rights Access Conditions RFU Algo Cks

Note: This information is used in the SelectCryptoContext command.

© GEMPLUS 2000

26 GPK Files

Where:

Where:

Tag_Nb 00h

Klgth 00h for 512 bits

10h for 768 bits

11h for 1,024 bits

Rights is coded as follows:

b7 b6 b5 b4 b3 b2 b1 b0

Val1 Val2 Typ1 Typ2 RFU RFU RFU Cert

Val1Val2 00b Not protected by secret code

01b Protected by SC1 (a secret code - see “Access Conditions” description that follows)

10b Protected by SC1 and SC2

11b Access is never

Typ1Typ2 00b Signature and unwrap key

01b Signature key

10b Unwrap key

11b Designates key as an Authority file, locked in ‘Write’ and ‘Update’, after the personalization phase. This is used to protect the Authority’s public key and prevent it from being overwritten by a PK_Send command (the PK_Send command checks these bits and does not overwrite the key elements if they are set to 11b). See “ PK_Send” on page 174 for more information.

Cert 0b Public key elements have not been certified

1b Public key elements have been certified, that is, signed by a CA. This bit is set for:

- Authority PK files during the personalization phase.

- PK files after a successful certificate verification.

© GEMPLUS 2000

GPK Files 27

,

Where:

The authorization rights are granted when the secret code(s) are correctly presented. The access conditions are checked each time a crypto session involving PK files is opened through the SelectCryptoContext command.

Access Conditions is coded as follows:

L1 SC1 L2 SC2

L1 (1bit) 0b The secret code file containing SC1 is at the global (MF) level.

1b The secret code file containing SC1 is at the local (DF) level.

SC1 (3 bits): The secret code number (from 0 to 7 at the level specified by the L1 bit) that must be presented to access the PK file.

L2 (1 bit) 0b The secret code file containing SC2 is at the global (MF) level.

1b The secret code file containing SC2 is at the local (DF) level.

SC2 (3 bits): The secret code number (from 0 to 7 at the level specified by the L1 bit) that must be presented to access the PK file.

Algo 00h - RSA

01h - DSA (see “Note on DSA” on page 4”)

Cks is a checksum, calculated as the binary sum of the five previous bytesthat is,

CKS = (B5 XOR B4 XOR B3 XOR B2 XOR B1 XOR A5h).

It is set when an update is done through a CreatePrivateFile command (for the private portion of a PK file) or through an Append Record of the system record (for public portion personalization).

© GEMPLUS 2000

28 GPK Files

RSA Public Key Elements

RSA public key elements may be used for verification and encryption.

File Contents Description Field Size Tag External Command Access

N Modulus N 01h Generate RSA Key ReadRecord PK_Send PK_Verify PK_OpenEnvelope

V for Verification Public Exponent N (max) 07h Generate RSA Key ReadRecord PK_Send PK_Verify PK_OpenEnvelope

Certificate Signature on V & N by a CA private key

N 08h ReadRecord PK_Send

Table 9 - RSA Public Key Elements

Caution: For V, only the significant part of V is stored, (leading zeroes are not stored).

Note: Public keys can be updated dynamically, throughout the life of the card, through the PK_Send command (except for keys in the Card Authority PK file), generated and loaded during the personalization phase.

© GEMPLUS 2000

GPK Files 29

DSA Public Key Elements (see “Note on DSA” on page 4)

DSA public key elements may only be used for verification.


P Prime 64 bytes 09h ReadRecord PK_Send PK_Verify

Q Subprime 20 bytes 0Ah ReadRecord PK_Send PK_Verify

G Base computed from (P,Q)

64 bytes 0Bh ReadRecord PK_Send PK_Verify

Y Public value 64 bytes 0Ch ReadRecord PK_Send PK_Verify

Certificate Signature on all public keys

≤ 64 bytes 0Eh ReadRecord PK_Send

Table 10 - DSA Public Key Elements

Note: Public keys can be updated dynamically, throughout the life of the card, through the PK_Send command (except for keys in the CA PK file).

© GEMPLUS 2000

30 GPK Files

RSA Private Key Elements

RSA private key elements are used for signing transactions (PK_Sign) and for internal authentication (PK_Int Auth).

File Contents Description Field Size

Tag External Command Access

S for normal processing Private Exponent used as signature key

N 04h Load Private Key PK_Int Auth PK_Sign

CRT for 512 & 768 bits Five CRT elements used as signature key

5N/2 05h Generate RSA Key Load Private Key PK_Int Auth PK_Sign

P (CRT element for 1,024 bits)

Prime 1 N/2 51h Generate RSA Key Load Private Key PK_Int Auth PK_Sign

Q (PxQ = N) (CRT element for 1,024 bits)

Prime 2 N/2 52h Generate RSA Key Load Private Key PK_Int Auth PK_Sign

Q^-1 mod p (CRT element for 1,024 bits)

Coefficient N/2 53h Generate RSA Key Load Private Key PK_Int Auth PK_Sign

S mod (P-1) (CRT element for 1,024 bits)

Exponent1 N/2 54h Generate RSA Key Load Private Key PK_Int Auth PK_Sign

S mod (Q-1) (CRT element for 1,024 bits)

Exponent2 N/2 55h Generate RSA Key Load Private Key PK_Int Auth PK_Sign

Table 11 - RSA Private Key Elements

Note: The 1,024-bit card stores the CRT elements separately in order to speed up processing.

Gemplus recommends that CRT is used to sign data.

The CRT elements used for signature are loaded in a specific order. For 512-bit and 768-bit keys, the elements are contained in a single record with Tag = 05h. The elements must be stored in the following order: Prime1||Prime2||Coefficient||Exponent1||Exponent2. For 1,024-bit keys, each element is stored in an individual record. This format is mandatory.

© GEMPLUS 2000

GPK Files 31

DSA Private Key Elements (see “Note on DSA” on page 4)

DSA private key elements are used for signing transactions (PK_Sign) and for internal authentication (PK_Int Auth).

Example Contents Of A PK File

Here is a list of the different PK elements that could be found in a PK file.

* See “Note on DSA” on page 4.


X Private Value 20 bytes 0Dh Load Private Key PK_Int Auth PK_Sign

Table 12 - DSA Private Key Elements

Note: The RSA and DSA key elements listed previously are all those that exist. However, depending on the application, not all of them may be needed. For example, for RSA signature with CRT, only CRT is used.

Caution: The key elements are loaded in the card in a specific proprietary format. This format must be adhered to during the personalization process if public key cryptography is to work correctly. See “Appendix F - Personalization Recommendations for PK_Crypto Applications” for the key format.

Algo Key length Public portion Private portion

RSA Normal mode (all key lengths)

n,v s

RSA CRT mode (all key lengths)

n,v CRT

DSA * 512-bit and 1,024-bit key lengths for signature

p,q,g,y x

Table 13 - Example of PK Elements

© GEMPLUS 2000

32 GPK Files

ted

nism f the

DF.

re

es

Transaction Manager FilesFDB value: 00010001b or 11h.

Each DF holding purse files must also hold a transaction manager file in order to recognize payment commands. The transaction manager file is a transparent EF and is eight bytes long. The MF and each DF can hold only one transaction manager file. The transaction manager file contains:

• A Card Transaction Counter (CTC). This is a three-byte counter that is incremenevery time a payment transaction session is established (each time the Select Purse & Key command is used). The CTC is used as a variable element for payment-oriented cryptographic processing.

• Backup CTC. Implemented using an automatic backup mechanism. The mechauses two registers (current value and previous value) to preserve the integrity ocounter.

Transaction manager files have the following structure:

Figure 15 - Transaction Manager File Structure

Field Description

Current CTC Stores the current value of the card transaction counter for the parent

Backup CTC Stores the value of the card transaction counter that was current befothe last transaction was executed.

Cks and Cks' Checksums. They are obtained by performing an XOR operation on thefirst three bytes of each word and inverting the final result.

Current CTC Cks

Backup CTC Cks’

Caution: The access conditions for updating and writing to transaction manager filmust be locked.

© GEMPLUS 2000

GPK Files 33

Secret Code Files

FDB value: 00100001b or 21h.

A secret code file is a transparent EF. The MF and each DF can store a maximum of one secret code Elementary File (EFsc). Only the first secret code file created in the DF (or MF) can be interpreted by the operating system. Each secret code file can store up to eight secret codes.

Secret codes are stored on eight bytes. The first four bytes correspond to the header, followed by a four-byte code value. The header values, excluding the checksum and the MPN, can be read using the Get Info command. The values of the codes themselves are inaccessible to the outside world. Secret codes are held at addresses 0 to 7. The number defines the order in which a secret code appears in the file. For example, the first secret code in a file corresponds to address 0, the second to address 1, and so on.

Secret codes have the following structure.

Figure 16 - Secret Codes Structure

Where:


Mode 1 nibble Defines whether the secret code is to be entered in plain or ciphered text on one nibble. It has the following format:

Figure 17 - Secret Code Mode

MPN 1 nibble Defines the Maximum Presentation Number on one nibble. This specifies the number of consecutive times that the secret code can be incorrectly entered before GPK blocks it. This number from 1 to 7 is coded on bits 0 to 2.

SCR 1 byte Secret Code Ratification counter. When a secret code is initialized this value is set to 00h by the operating system. The counter records the number of consecutive times that the secret code has been presented incorrectly. When the counter value reaches the MPN value, the card blocks the secret code. Each time the secret code is correctly entered, the card sets this value to 00h. However, once the code has been blocked, a successful presentation does not reset the counter to 00h (and does not unblock the secret code). To unblock a secret code, use the Set Code command to present the code specified in the UCR byte (see the following description of the UCR byte).

SCR UCR Cks

Secret Code (4 bytes)

Mode MPN 0h

; &

0b Enter secret code in plain mode1b Enter secret code in ciphered mode

;[;

© GEMPLUS 2000

34 GPK Files

e:

hen OR

s. st is

e

e

UCR 1 byte Unblock Code Reference. It specifies the secret code that must be entered to unblock the secret code for this header (see “ Set Secret Code” on page 117). This byte has the following structur

Figure 18 - Unblock Code Reference Structure

Cks 1 byte Checksum. The operating system calculates the checksum wupdating the secret code. The checksum is calculated as an Xoperation on all the other bytes (including the four-byte secretcode value) and then complementing the result.

Secret Code 4 bytes Secret code value. Terminals submit eight-byte secret codeWhen the card receives the secret code, GPK extracts the leasignificant nibble of each character. An eight-byte secret codetherefore stored on four bytes in the secret code file. This is shown in the following figure:

Figure 19 - Storing of a Secret Code

L Defines the level of the EFsc:

0 Specifies the Global EFsc

1 Specifies the Local EFsc

SCN Secret Code Number in the EFsc specified in L that must successfully submitted to unblock the secret codfor this header.

0 0 0 0 L SCN

ASCII Secret CodeE M P L U SG

Hexadecimal Value

45 4D 20 50 4C 55 5347

Secret Code Stored in Secret Code File

75 D0 0C 53

Note: For all applications, it is recommended that read access to secret code files bblocked.

© GEMPLUS 2000

GPK Files 35

le

Internal Application Data File (IADF)

FDB value: 00001001b or 09h.

The Internal Application Data File (IADF) is a specific file that can be interpreted by GPK in order to return information after the selection of a DF.

The IADF allows the implementation of the File Control Information (FCI) to be returned after the selection of a DF, as required by the EMV specifications. See EMV—IC Card Specifications for Payment Systems, Parts 1, 2, 3 for further information.

The IADF is a transparent file with a specific FDB value, and it is updated by using the Update Binary and Write Binary commands.

Any number of IADFs can be created in a DF, but only the first one can be interpreted by the operating system.

The IADF structure is shown in the following figure:

Figure 20 - IADF Structure

Where:

BS1 This byte defines the block size (in bytes) of Block 1, (that is, the size of the next field). If the indicated size is 0h (no Block 1), no FCI is returned by the card.

Block 1 Codes the Answer to Select FCI. This field is directly interpreted by GPK to build the response message when selecting the DF.

The global structure of Block 1 is as follows:

TLg Total length of the response in bytes.

Tn, Ln, Vn Represent a proprietary TLV format, interpreted by GPK.

Tn Represents a proprietary tag. GPK recognizes two tag values:

• Tn = 55h (direct addressing): Vn holds the data to be sent, and Ln holds its length.

• Tn = AAh (logical addressing): Vn holds logical information used by the Card to access the data, using fiaccess mechanisms. Ln holds the data length (and may be different from Vn length).

Note: If no IADF is attached to a given DF, standard system data is returned (see “ Select File” on page 111).

BS1 Block 1

BS2 Block 2

Field Description

TLg T1 L1 V1 T2 L2 V2 ...

© GEMPLUS 2000

36 GPK Files

t

ing ata

he

In this case, Vn is 3 bytes long and is coded as follows:

Where:

T Type (0: EF, 1: DF)

L Level (0: Global, 1: Local)

SFI Short File Identifier of the file (5 bits)

Offset/Rec.nb Most Significant Byte of offset in the case of a transparent file.Rec nb in the case of a structured file.

Offset Offset in bytes

• In the case of logical addressing, the offset is expressed in data units.

• In the case of logical addressing in a DF, the data forms part of the DFname.

• In the case of logical addressing and when accessing an EF, the Read access conditions should be unrestricted (the access conditions cannoactually be fulfilled at the time of the DF selection).

• In the case of inconsistencies (wrong tag, file not found, wrong offset, access conditions not fulfilled, length error and so on) encountered durthe IADF interpretation, the mechanism is aborted, and the remaining dis filled with zeroes.

• The sum L1+L2+...+ Ln must be equal to TLg.

BS2 This byte defines the block size (in bytes) of Block 2, (that is, the size of tnext field).

Block 2 Has no administrative meaning and may be used by the application.Example

Where:

T1 Indicates direct addressing is used

T2 Indicates logical addressing for file 1 (a transparent EF)

T3 Indicates logical addressing for file 2 (a structured EF)

V1 Holds data and is 8 bytes long

V2 Holds logical information for File 1 as follows:

V3 Holds logical information for File 2 as follows:

T L 0 SFI Offset/Rec.nb. Offset

BS1 TLg T1 L1 V1 T2 L2 V2 T3 L3 V3 BS2 Blck2

15h 24h 55h 08h data AAh 0Ch V2 AAh 10h V3 00h 00h

Bytes 1 1 1 8 1 1 3 1 1 3

T L SFI of File 1 Offset Offset

0 1 02h 00h 05h

T L SFI of File 2 Rec.nb. Offset

0 1 03h 04h 06h

© GEMPLUS 2000

© GEMPLUS 2000

3
Initial Status
mmon

red in s of

r cards n

Shipment ProcessesGPK cards can be delivered according to one of the two following delivery modes:

• Sample process, used to deliver sample cards. The cards are protected by a cokey.

• Secure process. The cards are protected by a diversified key. This key is delivea card called the customer key card, and is delivered separately from the batchecards. For additional information, please see the document called Customer Key Card Application Note.

Initialization ProcessesOnce the embedding step of the production process is complete, the microprocessoare initialized. The initialization process consists of writing the basic card informatiosuch as the card serial number, system files structure, and system keys.

GPK cards can be initialized according to one of the three initialization processes:

• -INTL: The unwrap function supports RSA keys with lengths of up to 56 bits. This option can be exported from France with no restrictions.

• -STD: The unwrap function supports RSA keys with lengths of up to 512 bits.This option can be exported from France with no restrictions.

• -FULL: The unwrap function supports RSA keys with lengths of up to 1,024 bits. This option is subject to individual export licenses.

The three processes have been developed for legal reasons (see “Legal Restrictions” on page 4).

Note: The required option must be specified by the customer when placing the order.

38 Initial Status

The cards initialized by these three different processes have a similar basic structure. This structure is shown in the following section:

Initial File Structure

Figure 21 - Initial File Structure

MasterFile

3F00h

EFKey File

3F01h

DFSystem

0100h

EFCard0101h

EFIssuer0102h

EFMax Session Key01FFh

EFSystem1FFFh

Note: The file EFSystem is not available in GPK16000.

© GEMPLUS 2000

Initial Status 39

ard’s

me

k

n

Master FileThe Master File (MF) is the root of the GPK file structure.

File Parameters

Security Access Conditions

EFKeyThis Elementary File (EF) contains the system key. This key is needed to carry out most personalization operations by the card application issuer. Its value depends on the cinitial status:

• For GPK cards initialized with the sample process, the value of this key is the safor all the cards: ASCII string TEST KEYTEST KEY.

• For GPK application cards initialized with the secure process, the key is diversified by Gemplus from a mother key that is stored inside a customer key card. The customer key card is delivered to the card issuer together with the batch of blancards (for more details, see the document, Customer Key Card Application Note).

File Parameters


Identifier: 3F00h

Name: none

The following options are fixed and cannot be changed by the issuer:

• ISO Dedicated File (DF)

• Cancel Debit command enabled

• Current balance can never be used to compute signature certificates.

Create data files: Secure messaging with EFKey 3F01h

Create sensitive files: Secure messaging with EFKey 3F01h

Caution: In order to allow new applications to be added in the future, no applicatioshould be loaded directly under the MF.

Identifier: 3F01h

Body Size: 24 bytes

Read: Locked

Write: Secure messaging with EFKey

Update: Secure messaging with EFKey

© GEMPLUS 2000

40 Initial Status

tly

DFSystemThis is the DF containing the system EFs.

File Parameters


EFCard FileThis is an EF containing, in order, the following:

• Card Serial Number (CSN), on 8 bytes, issued by the card manufacturer.

• Gemplus Issuer Reference Number, on 4 bytes.

File Parameters


Identifier: 0100h

Name: SYSTEM

The following options are fixed and cannot be changed by the issuer:

• ISO DF

• Cancel Debit command enabled

• Current balance can never be used to compute signature certificates.

Create data files: Secure messaging with EFKey 3F01h

Create sensitive files: Secure messaging with EFKey 3F01h

Caution: This DF is dedicated to system data. No application must be loaded direcunder DFSystem

Identifier: 0101h

Body Size: 12 bytes

Read: Public

Write: Locked

Update: Locked

© GEMPLUS 2000

Initial Status 41

Card Serial NumberThe Card Serial Number (CSN) is unique for each GPK card and it cannot be modified. It is coded on eight bytes (two words of 32 bits) as follows:

Where:

Gemplus Issuer Reference NumberThe Gemplus Issuer Reference Number is coded on four bytes (three bytes plus a checksum). This number is provided by Gemplus as a unique reference for each customer and cannot be updated. It is recommended that this issuer code be used as a reference in your application.

In sample cards, the Gemplus Issuer Reference Number is set to 00 FF 00h (plus the checksum which is 10h).

Bits

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00

[1 10 bits ][2 22 bits ]

[3 10 bits ][4 6 bits ][5 8 bits ][6 8 bits ]

Figure 22 - Card Serial Number Structure

1: Batch Number (10 bits)

2: Serial Number (part) (22 bits)

3: Serial Number (part) (10 bits)

4: Week Number (06 bits)

5: Serial Number (part)

Production site coded as follows:00: Gemenos

01: Filderstadt

02: Montgomeryville

03: La Ciotat04: Japan

05: Singapore

06: Contactless (Gemenos)07: Cuernavaca

08: Tianjin

09: Engineering development (Gemenos)10: Development perso (Gemenos)

11: Development perso (Singapore)

12: Manufacturing (Sao Paulo)13: Manufacturing (Herne)

14: Manufacturing (Havant)

(08 bits)

6: Year of Manufacture (08 bits)

Fields 2, 3, and 5 make up the serial number in a batch.

Note: Gemplus reserves the right to modify the structure of the card serial number.

© GEMPLUS 2000

42 Initial Status

EFIssuerThis is an EF containing in order, the following:

• Issuer Serial Number, on 8 bytes.

• Issuer Reference Number, on 4 bytes

This information is written by the card application issuer during the personalization phase.

File Parameters


EFMaxSessionKeyThis is an EF containing the maximum length of data that the card can unwrap. Thisinformation is stored during the initialization phase of the card.

File Parameters


Identifier: 0102h

Body Size: 12 bytes

Read: Public

Write: Secure messaging with EFKey (in the MF)

Update: Secure messaging with EFKey (in the MF)

Identifier: 01FFh

Body Size: 1 byte

Read: Public

Write: Not authorized

Update: Not authorized

© GEMPLUS 2000

Initial Status 43

g is

EFSystemThis system file, reserved by Gemplus, is loaded during the initialization phase of the card.

File Parameters


Personalization FlagIn their initial status, the cards’ personalization flag is not set, that is it is zero. The flaset to 1 once you have completed personalization. Setting this flag shows you haveswitched to user mode. It is set by the Set Card Status command. For more information,refer to this command.

See also “GPK Personalization” on page 196.

IO Buffer SizeThe GPK IO buffer size is 64 bytes for all the cards. However, GPK manages chaining for normal processing. This means that a command breaks down data into smaller blocks (64 bytes) for processing. The maximum data does not depend on the buffer size, but is specified for each APDU command.

For example, without secure messaging, it is possible to update a record of up to 255 bytes. However, when secure messaging is used, since chaining is not allowed the buffer size does apply, so data is limited to 61 bytes (buffer size of 64 bytes minus 3 bytes for the cryptographic checksum).

Identifier: 1FFFh

Read: Not authorized

Write: Not authorized

Update: Not authorized

Note: The file EFSystem is not available in GPK16000.

© GEMPLUS 2000

44 Initial Status

after

EEPROM SizeThe following EEPROM size is available to the user based on the product option (after initialization of the card).

Gemplus has reserved EPROM and EEPROM areas not accounted for in the accessible file structure for security and life management of the product (for example, Witness cells, personalization status). These bytes are used only by the operating system of the card and cannot be accessed by any standard command issued at the interface.

Lock ByteThe lock byte can be read from a GPK card using the Get Info command. It is updated using the Set Card Status command. See “ Get Info” on page 100 and “ Set Card Status” on page 116 for more information.

The structure of the Lock Byte is as follows:

Figure 23 - Lock Byte Structure

Product Option Available EEPROM Size

GPK8000 7.4 Kbytes

GPK16000 15.4 Kbytes

Table 14 - Available EEPROM Size for the GPK Range

Note: These capacities correspond to the amount of EEPROM available to the userinitialization by Gemplus (that is, after the MF and DFSystem have been created).

7 6 5 4 3 2 1 0

Bprot Data Unit

0 DSA Bissuer

(PERSO)

1 1 RFU (0)

Where:

Bprot 0 Double Reset Mechanism disabled.1 Double Reset Mechanism enabled.

Data Unit 0 4-byte data unit (compatible with the earlier MPCOS version). 1 1-byte data unit (as required by EMV specifications).

DSA 0 DSA algorithm not available. 1 DSA algorithm available (see “Note on DSA” on page 4).

Bissuer (PERSO)

Set to 1 when the personalization has been completed, and the card becomes user mode.

© GEMPLUS 2000

© GEMPLUS 2000

4
Access Conditions
o ecure ile

or

) and able

F.

nly

GeneralGPK cards allow file access to be protected using secret codes or secret 3DES keys. Secret codes are stored in secret code Elementary Files (EFsc). The Master File (MF) and each Dedicated File (DF) can hold one EFsc (see “Secret Code Files” on page 33).

When a terminal attempts to access data stored in an Elementary File (EF), the card checks the EF access condition to see if the file is secret code protected for the type of access attempted (Update, Append / Write, Read). If the file is secret code protected, the card checks the appropriate authorization register to see if the secret code has been successfully presented.

Access conditions are found in DF and EF descriptors. They contain two parts:

• A Group AC that determines the level of protection. Each type of access (Update, Append / Write, Read) can be protected by up to two secret codes. This part alscontains information about the 3DES key used to generate session keys for all smessaging with the file. This information is the level (global or local) and Short FIdentifier (SFI) for the key file. The Group AC is stored in the fixed part of the DFEF file descriptor.

• An AC Secret Code Reference that specifies the secret code file (global or localthe secret code number(s). The AC Secret Code Reference is stored in the varipart of the DF or EF file descriptor.

Data protection conditions can be defined by the application issuer for each EF or D

Note: 3DES keys can only be used to compute CRYCKS; they cannot be used to encrypt data.

3DES-based cryptography is not used to prevent data from being read, it is oused to guarantee that the data that is being read is from a genuine card.

Secure messaging is not an access condition.

46 Access Conditions

ully o

lly alled

ow

.

ith

t code c

Example

An application issuer creates a data EF requiring the terminal to perform the following steps before data can be accessed:

1. Select the parent DF.

2. Ask the cardholder to type in his/her PIN code; (Read access to this EF is protected by PIN code presentation).

3. Submit this code to the card.

When the terminal submits a secret code, it specifies a secret code number from 0 to 7. The card compares the secret code submitted with the secret code specified by the EFsc.

If the secret codes do not match, GPK returns an error status byte. If the secret codes do match, GPK sets the bit number corresponding to the number of the successfully submitted secret code to 1 in an authorization register (see “Authorization Registers” on page 49). There are two authorization registers:

• The MF authorization register records the secret codes that a terminal successfsubmits while the MF is selected, that is, the EFsc at the global level. This is alscalled the global level register.

• The DF authorization register records the secret codes that a terminal successfusubmits while a DF is selected, that is, the EFsc at the local level. This is also cthe local level register.

The following sections describe access conditions and authorization registers, and hGPK manages them.

Access ConditionsAccess conditions specify the following:

• The secret codes that must be submitted before access can be granted to a file

• The 3DES key file containing the key used for secure messaging transactions wthe file (see “Secure Messaging” on page 59).

Access conditions are initialized by the Create File command when the file is created. They can also be locked or localized using the Freeze AC command at any stage in the card’s life cycle.

• Locking an access condition means setting it to 1 so that access is permanentlyrefused.

• Localizing an access condition means moving the access condition key or secrereferences from the MF EFKey and EFsc files to the parent DF EFKey and EFsfiles.

© GEMPLUS 2000

Access Conditions 47

a file

roup.

There are three groups of access conditions in each GPK file. These are shown in the following table:

Table 15 - Groups of Access Conditions

Data files are EFs that contain data, that is not interpreted by the card. GPK recognizes these files by their File Descriptor Byte. Bits 5–3 are set to 000b. For example, a datmay be one that contains the card holder's address.

Sensitive files contain data that is interpreted by the card. The following files are sensitive files (bits 5–3 of the FDB are shown between parentheses):

• All DFs (b5b4b3 = 111b)

• 3DES key and public key EFs (b5b4b3 = 101b)

• Secret code EFs (b5b4b3 = 100b)

• Purse and enhanced purse EFs (b5b4b3 = 011b)

• Transaction Manager EFs (b5b4b3 = 010b)

• Internal Application Data File (b5b4b3 = 001b)

Access conditions can assign the following levels of security to a file:

• Not secret code protected (with or without secure messaging; see “Secure Messaging” on page 59)

• Protected by one secret code (with or without secure messaging)

• Protected by two secret codes (with or without secure messaging)

• Access never allowed

The secret codes protect files for the operations defined in each access condition g

Access conditions are made up of two bytes:

• Group AC - stored in the fixed part of the file descriptor

• AC Secret Code Reference – stored in the variable part of the file descriptor

For further details on the file descriptor, see “File Descriptor” on page 6 for DFs and “File Descriptor” on page 11 for EFs.

Group # In a Dedicated File In an Elementary File

1Create sensitive files Update Binary

Freeze AC in sensitive files Update Record

2Create data files Write Binary

Freeze AC in data files Append Record

3 Not usedRead Binary

Read Record

© GEMPLUS 2000


ion

The Group AC is coded as follows:

The following figure shows how a group access condition is coded:.

Figure 24 - Coding of Group Access Conditions

Where:

Val is the validity field. This defines the group protection level as follows:

L defines the level of the EFKey file.

Key File is the SFI of the key file (5 bits), at the level specified in L, that contains the key that the Select File Key command used to generate the temporary key (see “ Select File Key” on page 114) for the current administration transaction session. Alternatively, this key could be a log key used by theSelect Purse & Key command. If the key used to generate the temporary key is not in the file specified here, access is denied to the access conditgroup for secure messaging. If the SFI is zero, secure messaging is not needed to transact with the access condition group.

Bit 7 6 5 4 3 2 1 0

Val L Key File

00b No secret code protection.

01b File protected by the secret code specified in SCN1 (and possibly secure messaging, see the field “Key File”).

10b File protected by the secret codes specified in SCN1 and SCN2 (and possibly secure messaging, see the field “Key File”).

11b Access never allowed.

0b Global level

1b Local level

© GEMPLUS 2000


codes.

the at the

vel at

e ds

et

The following figure shows how an AC secret code reference is coded:

Figure 25 - Coding of AC Secret Code Reference

Where:

Authorization RegistersAuthorization registers are eight-bit RAM registers that keep a record of the successfully entered secret codes. GPK manages two authorization registers:

• The MF authorization register to store security status at the global level

• The local DF authorization register to store security status at the local level

Each authorization register can record the correct presentation of up to eight secret

Each time a secret code is successfully entered using the Verify command, the card writes a 1 to the corresponding bit in the authorization register for the level at whichsecret code was presented. For example, if secret code 2 is successfully submitted local level, bit number 2 in the DF authorization register is set to 1.

L1 defines the level of the EFsc file containing SCN1.

SCN1 defines the first secret code number (0 to 7) in the EFsc for the lespecified in L1 that has to be entered to perform the commands thbelong to that group.

L2 defines the level of the EFsc file containing SCN2.

SCN2 defines the second secret code number (0 to 7) in the EFsc for thlevel specified in L2 that has to be entered to perform the commanthat belong to that group.

Bit 7 6 5 4 3 2 1 0

SCN1 SCN2L1 L2

0b Global level

1b Local level

0b Global level

1b Local level

Warning: For payment-dedicated commands (Debit, Credit, Read Balance). Secret Code 0 means unrestricted access (not “protected by Manufacturer SecrCode”).

© GEMPLUS 2000


ts a

GPK cards manage authorization registers according to the following rules:

• The card sets all authorization registers to zero when it is reset.

• The card sets the DF authorization register to zero each time the terminal selecnew DF (even if the new DF is the same file as the previously selected DF).

• The card never sets the MF authorization register to zero during a session.

Example

The following example shows how the GPK data protection system works.

7HUPLQDO *3.�&DUG $XWKRUL]DWLRQ�5HJLVWHU�6WDWXV�DIWHU�FRPPDQG�FRPSOHWLRQ

0)�/HYHO*OREDO

')�/HYHO/RFDO

5HVHW�&DUG 6HW�DXWKRUL]DWLRQ�UHJLVWHUV�WR�]HUR��6HOHFW�0)

9HULI\�6HFUHW�&RGH�;<=��1R��

&RPSDUH�YDOXH�;<=�ZLWK�6HFUHW�&RGH�1R��LQ�0DVWHU�)LOH�()VF��,I�WKH�VHFUHW�FRGH�LV�FRUUHFW��XSGDWH�WKH�0)�DXWKRUL]DWLRQ�UHJLVWHU�

&UHDWH�'HGLFDWHG�)LOH &KHFN�0)��$&�6HFUHW�&RGH�5HIHUHQFH�IRU�*URXS��

6&1�� ELW��LQ�0)�$XWKRUL]DWLRQ�5HJLVWHU ��$OORZ�$FFHVV

6HOHFW�'HGLFDWHG�)LOH�� 6HOHFW�'HGLFDWHG�)LOH��

9HULI\�6HFUHW�&RGH�$%&��1R��

&RPSDUH�YDOXH�$%&�ZLWK�6HFUHW�&RGH�1R��LQ�')��()VF��,I�WKH�VHFUHW�FRGH�LV�FRUUHFW��XSGDWH�WKH�')�DXWKRUL]DWLRQ�UHJLVWHU�

6HOHFW�(OHPHQWDU\�)LOH�� 6HOHFW�(OHPHQWDU\�)LOH��

:ULWH�WR�(OHPHQWDU\�)LOH &KHFN�()��$&�6HFUHW�&RGH�5HIHUHQFH�IRU�*URXS��

6&1�� 6&1�� 0)�$XWKRUL]DWLRQ�5HJLVWHU�ELW�� ')�$XWKRUL]DWLRQ�5HJLVWHU�ELW�� $OORZ�DFFHVV

6HOHFW�'HGLFDWHG�)LOH�� 6HOHFW�'HGLFDWHG�)LOH��

� � � � � � � � � � � � � � � �

� � � � � � � ��

� � � � ; [ [ [

6&1��

()VF�DW�0)�/HYHO

� � � � � � � ��

� � � � � � � ��

� � � � � � � �

6&1�� ()VF�DW�0)�/HYHO

()VF�DW�')�/HYHO6&1��

� � � � � � � ��

© GEMPLUS 2000


9HULI\�6HFUHW�&RGH�'()��1R��

&RPSDUH�YDOXH�'()�ZLWK�6HFUHW�&RGH�1R��LQ�')��()VF��,I�WKH�VHFUHW�FRGH�LV�FRUUHFW��XSGDWH�WKH�')�DXWKRUL]DWLRQ�UHJLVWHU�

6HOHFW�(OHPHQWDU\�)LOH�� 6HOHFW�(OHPHQWDU\�)LOH��

5HDG�IURP�(OHPHQWDU\�)LOH &KHFN�()��$&�6HFUHW�&RGH�5HIHUHQFH�IRU�*URXS��

6&1�� 6&1�� 0)�$XWKRUL]DWLRQ�5HJLVWHU�ELW�� ')�$XWKRUL]DWLRQ�5HJLVWHU�ELW�� $FFHVV�QRW�DO ORZHG

7HUPLQDO *3.�&DUG $XWKRUL]DWLRQ�5HJLVWHU�6WDWXV�DIWHU�FRPPDQG�FRPSOHWLRQ

0)�/HYHO*OREDO

')�/HYHO/RFDO

� � � � � � � ��

� � � � � � � ��

� � � � � � � �

6&1�� ()VF�DW�0)�/HYHO

()VF�DW�')�/HYHO6&1��

© GEMPLUS 2000

© GEMPLUS 2000

5
GPK DES-Based Cryptography
s). nd

tely

3DES Algorithm.

3DES can be implemented to achieve various security scheme requirements

This cryptographic algorithm is the secret key symmetric algorithm: “3DES” in EDE mode (cf. standards ANSI X9.17).

3DES requires the use of keys that are 16 bytes long (also called double-length keyThis 3DES key thus consists of a key K (Kl: Kr) where Kl is the left part of the key aKr is the right part of the key.

The following figure shows how 3DES is implemented in GPK (this takes approxima40 ms):

Figure 26 - Triple DES Implementation in EDE Mode

DES

DES

DES

Data (8 bytes)

Kl

Kl

Kr-1

Encrypted Data (8 bytes)

54 GPK DES-Based Cryptography

The inverse function 3DES-1 is as shown in the following figure:

Figure 27 - Inverse Triple DES Implementation

Key DiversificationThe card computes a temporary diversified 3DES key SK (SKl; SKr) from a card secret 3DES key K (Kl; Kr) as shown in the following figure:

Figure 28 - Temporary Diversified 3DES Key

The card thus has a temporary diversified 3DES key SK (SKl; SKr). This temporary key can be used to compute certificates during transactions.

Notation for 3DES key diversification: SK = 3DES_16(data,K).

DES

DES

DES

Encrypted Data (8 bytes)

Kl

Kl

Kr

Plain Data (8 bytes)

-1

-1

DES

DES

DES

Input data Input data

Kr

Kl

Kl

Kl

Kr

Kr

Diversified Key Left (SKl) Diversified Key Right (SKr)

8 bytes long

8 bytes long 8 bytes long

-1

DES

DES

DES-18 bytes long

8 bytes long

8 bytes long

8 bytes long

8 bytes long

8 bytes long8 bytes long

Temporary diversified 3DES key : SK (SKl; SKr)

Note: 3DES_16 gives a result of 16 bytes, while 3DES gives a result of 8 bytes.

For key diversification, 3DES is used in ECB (Electronic Codebook) mode.

© GEMPLUS 2000

GPK DES-Based Cryptography 55

Authentication/Computation of CertificatesCertificates or authentication cryptograms are computed using 3DES as follows:

Figure 29 - Certificate Computation

Cryptographic ChecksumCryptographic checksums (CRYCKS) are used in the secure messaging process in GPK, in particular they are used by the data management and other commands (such as Update Binary, Write Binary, Create File).

The CRYCKS is calculated using the whole of the data to be exchanged between the card and the terminal (including the command header at the beginning). The CRYCKS is computed using the Cipher Block Chaining (CBC) mode.

The CBC mechanism begins by concatenating the data to the command header and dividing the result into eight-byte blocks. If the resulting data is not a multiple of eight bytes, the last block is padded with zeroes as described in the next paragraph. The result of each encrypted block is fed back into the encryption of the next block by means of an XOR operation as shown in the following diagram:

Figure 30 - CRYCKS Computation

DES

Data to be certified

SKr

SKl

SKl

Ciphered data

8 bytes long

8 bytes long

8 bytes long

8 bytes long

-1DES

DES

Certificate = part of the ciphered data (e.g., 3 bytes)

8 bytes long

3DES

Key

Block 1 XOR R 1

3DES

Key

Block 2 XOR R 2

3DES

Key

Block n XORR n =

Initialization block (zero-filled)

Plaintext Ciphertext

CRYCKS

© GEMPLUS 2000


The following example shows how to compute the CRYCKS as required to update data in the card.

The data is arranged in blocks of eight bytes. The first data block, Block 1 comprises the five bytes of the header (CLA, INS, P1, P2, Lc) plus the first three bytes of data. Subsequent blocks, Block 2, Block 3 and so on,. contain the rest of the data in blocks of eight bytes. In this example, the final block has six bytes of data, so the final two bytes are zero-padded.

The cryptographic checksum is calculated as follows:

Kts is the temporary session key.

1. R1 is calculated as 3DES(Block 1, Kts).

2. R2 is calculated as 3DES(Block 2 XOR R1, Kts).

3. This is repeated for each block of eight bytes, with the result of one computation (Ri) being used in the next one (Ri+1).

4. Rn is the final computation, using the final data block, Block n and is calculated as 3DES(Block n XOR Rn-1, Kts).

5. CRYCKS is the result of this final computation (that is, Rn).

Only the three LSB of the CRYCKS are used for the Update Binary command in secure messaging.

Zero-PaddingAs all the DES-based cryptography features used in the GPK card are based on the 3DES algorithm, the length of the data to be enciphered, deciphered or signed must be a multiple of eight bytes. If this condition is not satisfied, zero padding is performed on the last block of eight bytes, as shown in the following figure:

Figure 31 - Zero - Padding Method

This padding corresponds to the method 1 described in the ISO/IEC 9797 standard.

CLA INS P1 P2 Lc Data(3 bytes)

Data(8 bytes)

... Data (6 bytes)

00 00

Block 1 Block 2 ... Block n

b063b

Block 1

b063b

Block 2

b063b

Block n

PaddingData to be ciphered, deciphered or signed

0 0 0 0 0 0 ... 0

© GEMPLUS 2000


nt ed in

es

on of

See

the

GPK 3DES KeysGPK keys can be used for the following processes:

• Decrypting secret codes/keys

• Computing certificates and signatures

• Internal and external authentication

• Secure messaging

Keys are supplied in one of the two following ways:

• They can be retrieved from 3DES key files, which are initialized during the card personalization.

• They are generated by GPK (temporary keys).

Key Types Loadable in CardsKeys initialized during card personalization are loaded in 3DES key files. The differetypes of keys are stored in separate 3DES key files. The type of key is actually definthe 3DES key file header.

Different types of keys can be used in GPK. For further information on these key typsee “Table 7 - Key Types” on page 23.

3DES cryptographic keys (16 bytes long) are actually stored as 24 bytes since these are stored as two consecutive DES keys.

In a given DF, several 3DES key files can be created. When designing an application, it is recommended that a 3DES key file be created for each function. For instance a 3DES key file should be created to store keys dedicated to authentication.

Temporary Keys Generated by GPKOther types of keys can also be generated by GPK on the basis of keys stored in the card:

• A temporary administration key is generated when the Select File Key command is executed, starting a new administration session. This key is used for the securemessaging process.

• A temporary certification key is generated when the Select Purse & Key command is executed, starting a new transaction session. This key is used in the generaticertificates and during most encryption procedures.

• A temporary signature key is used by GPK to generate the signature certificate.“ Sign” on page 155 for further details.

• A temporary credit key is generated by the host or by a terminal when the Credit command is executed, and used to encrypt and decrypt transmissions betweenhost, terminal, and the card. For further details, see “ Credit” on page 142.

© GEMPLUS 2000


er

Example

GPK generates temporary certification keys using the following formula:

Key = 3DES_16 (CTC, Ks)

Where:

When Temporary Keys Are LostA temporary certification or administration key is lost under any of the following circumstances:

• Card reset

• Selection of a new DF, unless selected from the MF.

• Execution of the Sign command in Terminate mode (see “ Set Options” on page 153) (temporary signature keys).

• Execution of the Credit command (temporary credit keys).

• Execution of the SelectCryptoContext command (temporary credit keys).

• Security error due to secure messaging.

• Incorrect execution of the Read Balance command.

• Incorrect execution of the Select File Key or Select Purse & Key commands.

• Change of session (administrative/payment), that is, a new Select File Key or Select Purse & Key command has been executed.

Cryptographic Security ImplementationGPK can use the following cryptographic security features:

• Card/terminal authentication

• Secure administration command transmission using secure messaging

• Generation of payment certificates/signatures

• Payment command transmission protection using cryptograms

Card/Terminal AuthenticationGPK cards support two authentication processes. These are as follows:

• Internal Authentication: the card proves it is genuine to the external world. For further details see “ Internal Authenticate” on page 105.

• External Authentication: the real world proves it is genuine to the card. For furthdetails see “ External Authenticate” on page 93.

CTC is the Card Transaction Counter (see “Transaction Manager Files” on page 32).

Ks is a key selected from a 3DES key file.

© GEMPLUS 2000


ss

er in

g key

ield.

Secure MessagingGPK protects administration command transmissions between cards and terminals using secure messaging. Secure messaging implements either of the following processes:

• Encrypting data sent to the card. This is used with the Write Binary command when writing to an EFsc or an EFkey, the Update Binary command when updating an EFsc or an EFkey, and the Verify command. Each command uses a different proceto encrypt transmissions, refer to the respective command descriptions in “Chapter 11 - Administration Commands” for details.

• Sending three bytes of a cryptographic checksum with the command so that thereceiver can verify the integrity of the transmission. This process is described latthis section.

The following conditions must be met before secure messaging can be used:

• The Select File Key command must have been executed to establish an administration session (see “ Select File Key” on page 114), or the Select Purse & Key command must have been executed to establish a temporary key using a lo(see “ Select Purse & Key” on page 150).

• The 3DES key file specified in the Key File field in the access condition for the required access type, must be one of the following:

− the 3DES key file that holds the key used by the Select File Key to generate the temporary administration transaction key (see “Chapter 4 - Access Conditions”).

− the 3DES key file that holds the log key used by Select Purse & Key to generate a temporary key.

The terminal notifies the card that it is using secure messaging by entering ’84’ or ’04’ in the command APDU class field.

Sending Data to the Card with Secure MessagingFor commands that send data to the card (such as Update or Create), the terminal performs the following actions:

1. Divides the command transmission into eight-byte blocks as described in “Cryptographic Checksum” on page 55.

2. Generates the cryptographic checksum based on all the eight-byte blocks using the temporary administration key.

3. Adds the three LSB of the cryptographic checksum (CRYCKS 2–0) to the data f

4. Sends the command APDU in the following format:

Figure 32 - Secure Messaging Command when Sending Data

04/84 INS P1 P2 Lc Data + CRYCKS2–0 03

Le Value

Data and Cryptographic Checksum: Length = Lc-3

CLA Field Value

Lc Value

© GEMPLUS 2000


ss for

The card performs the following actions:

1. Generates a cryptographic checksum for the command it receives using the same process as the terminal. It verifies that the three LSB of the checksum that it generates match CRYCKS 2–0. If the bytes do not match, the card denies accethat command.

2. Executes the command.

3. Returns the SW1, SW2 bytes and makes the three MSB of the generated cryptographic checksum available:

Figure 33 - Secure Messaging Response when Sending Data

Retrieving Data from the Card with Secure MessagingFor commands that only retrieve data from the card (such as Read), the terminal sends the command in the following format:

Figure 34 - Secure Messaging Command when Retrieving Data Only

The card performs the following actions:

1. Divides the return transmission into eight-byte blocks as described in “Cryptographic Checksum” on page 55.

2. Generates a cryptographic checksum based on all the eight-byte blocks and the temporary administration key.

3. Returns the SW1, SW2 bytes and makes the response data and the three MSB of the cryptographic checksum available:

Figure 35 - Secure Messaging Response when Retrieving Data Only

CRYCKS7–5 SW1, SW2

Cryptographic Checksum

04/84 INS P1 P2 Empty Le

Le Value

Data Field:

CLA Field Value

Lc Field

Empty

Note: In this case the first block consists of the command header (CLA, INS, P1, P2, Le), and the first three bytes of the data field.

CRYCKS7–5 SW1, SW2

Cryptographic Checksum

Data

Note: You should refer to specific commands for further details on secure messaging (see Read Binary, Update Binary, Write Binary, Read Record, Append Record, Update Record, Create File, Verify, and Set Secret Code commands in “Chapter 11 - Administration Commands”).

© GEMPLUS 2000


should

Payment CertificatesGPK cards generate certificates after performing the following payment actions:

• A debit, which is performed by the Debit command.

• Reading a purse balance, which is performed by the Read Balance command.

• Canceling a previous debit, which is performed by the Cancel Debit command.

The card can also generate a signature when requested. For more details, see “ Sign” on page 155.

The process used to generate the certificate is different for each command and you refer to the individual command descriptions in “Chapter 12 - Payment Commands”.

Certificates can be recorded and then used by the terminal/host system to validate a payment transaction.

Example

After a debit, and depending on the personalization options GPK cards generate transaction certificates as follows:

Where:

Terminal Transaction CountersEach terminal stores and maintains a Terminal Transaction Counter (TTC). GPK cards and terminals use TTCs during payment-related cryptographic procedures. They provide a variable element that can be used to identify a terminal and the transactions that it performs.

Each TTC is one word long and is structured as follows:

Bytes TTC3 and TTC2 store a terminal number that is defined and maintained by the application. This must be a unique hexadecimal number for each terminal used in the system.

Bytes TTC1 and TTC0 are to be used as a counter that the terminal increments each time it executes a Debit, Credit, or Cancel Debit command.

Certificate = 3DES ( 00h Pn Tv2 Tv1 Tv0 TTC2 TTC1 TTC0 , Kpts )

Pn Specifies the SFI of the purse on which the transaction was executed.

Tv2 to Tv0 Specify the transaction value.

TTC2 to TTC0 This is a three-byte value that GPK cards use to keep track of transactions executed with each terminal. This is described in “Terminal Transaction Counters” on page 61.

Kpts Temporary payment transaction key.

TTC3 TTC2 TTC1 TTC0

© GEMPLUS 2000


Payment Command CryptogramsDuring payment transaction sessions, GPK cards and terminals generate cryptograms that can be used to verify the integrity of the transmission. Cryptograms are generated during the following operations:

• Crediting a purse. For more details, see “ Credit” on page 142.

• Starting a transaction session. For more details, see “ Select Purse & Key” on page 150.

• Canceling a previous debit. For more details, see“ Cancel Debit” on page 138.

Each command has a specific means of generating cryptograms. Refer to “Chapter 12 -Payment Commands” for further details.

© GEMPLUS 2000

© GEMPLUS 2000

6
GPK Public Key Cryptography
tion

Hash AlgorithmsTwo hash functions are available in GPK:

• SHA - The Standard Hash Algorithm Version 1

• MD5 - Message Digest Version 5

In both cases the data to be hashed is loaded using the PutCryptoData command.

SHAThe Standard Hash Algorithm is used before either RSA or DSA signature or verifica(see “Note on DSA” on page 4).

The SHA is included in the ANSI X9.31 Digital Signature standard - so it is mandatory before DSA. See “For More Information” on page x for the full title of this standard.

The data to be hashed is in blocks of 64 bytes. The final SHA result is always 20 bytes long, irrespective of the number of blocks of data.

Figure 36 - SHA Algorithm Processing

SHAFactors

20 bytes

Plain Block 1

(64 bytes)

Plain Block 2

(64 bytes)

Plain Block N

(64 bytes)

SHA SHA

20 bytes 20 bytes 20 bytes

SHA result

64 GPK Public Key Cryptography

MD5This algorithm, Message Digest version no. 5, may only be used before an RSA signature or verification.

The data to be hashed is in blocks of 64 bytes. The final SHA result is always 16 bytes long, irrespective of the number of blocks of data.

Figure 37 - MD5 Algorithm Processing

The SHA and MD5 hashing algorithms can be combined (in SSL mode) for PK signing and PK Internal Authentication. For further details, see “Public Key Commands” on page 68.

Padding for SHA & MD5For both SHA and MD5, the data to be hashed must be in blocks of 64 bytes.

The message to be hashed is padded so that its length is just eight bytes short of being a multiple of 64 bytes. This padding consists of a single 1 (in the first bit following the end of the message), followed by as many 0’s as required. Then, an eight-byte representation of the length of the message (before padding) is appended to the result. These two steps serve to make the message length an exact multiple of 64 bytes, while ensuring different messages will not look the same after padding.

MD5Factors

16 bytes

Plain Block 1

(64 bytes)

Plain Block 2

(64 bytes)

Plain Block N

(64 bytes)

MD5 MD5

16 bytes 16 bytes 16 bytes

MD5 result

Note: This padding is mandatory even if the total length of the data is a multiple of 64 bytes. In this case, the last block consists of a first byte ’80h’ followed by as many 0’s as required. Then, an eight-byte representation of the length of the message; (that is, the length of the data before padding) is appended to the result.

For GPK, this padding is automatically performed by the card just after the last block has been loaded using the PutCryptoData command, according to the size of the whole message.

© GEMPLUS 2000

GPK Public Key Cryptography 65

h the

is in

h is

Padding for RSAThe PK_OpenEnvelope, PK_IntAuth and PK_Sign commands can specify a padding to use with the RSA algorithm. There are three possible types of padding:

• PKCS#1

• ANSI X9.31

• ISO 9796-2

PK-Algorithms

RSA512-bit, 768-bit and 1,024-bit keys:

• Signature is computed with either the Chinese Remainder Theorem, CRT, or witmodulus N and exponent s, if no CRT is found in the private PK file.

• Verification is computed by using the modulus, N and the public exponent, v.

DSA512-bit and 1,024-bit keys (see “Note on DSA” on page 4):

• Signature is computed with the elements P, Q, G and the private Value X -whichthe private portion of the PK file.

• Verification is computed with the elements P, Q, G and the public Value Y -whicin the public portion of the PK file.

GPK Public KeysGPK public keys can be used for the following processes:

• Signing transactions

• Verifying transactions

• Internal authentication

• External authentication

• Certificate verification

• Unwrapping

For further information on public keys, see “Public Key Files” on page 24.

Note: Key size is equal to the size of the modulus N for all three key sizes.

© GEMPLUS 2000


byte,

h the

Public Key Cryptography ImplementationAccess to the keys in the PK file is governed by the access conditions byte in the system record at the start of each part of the file. The system record at the start of the public portion governs the public keys, while the system record at the start of the private portion of the file governs the private keys.

The access conditions are checked using the SelectCryptoContext command. The access conditions must be fulfilled to be able to use the following commands:

• PutCryptoData

• InitHashedData

• PK_Sign

• PK_Verify (in both “Verify” and “Verify Certificate” mode)

• PK_Int Auth

• PK_OpenEnvelope

For detailed information on the coding of the system record and the access conditionsee “Public Key Files” on page 24.

Public Key CertificationThe PK_Verify command uses an IFD (such as a terminal) public key (previously sent to the card using a PK_Send command).

It is mandatory to certify any IFD public key (RSA/DSA - see “Note on DSA” on page 4) before it may be used (that is, the GPK card verifies the corresponding RSA/DSA certificate). A certificate is the signature of a set of keys by the Certificate Authority to confirm that the keys have been authorized.

The certificate is verified using the Authority public key, PuK_Ca. The card compares the certificate verification result with the transmitted data, which includes the IFD public key (RSA/DSA). If the comparison is successful, the certification status is set to 1 in the card (see “The System Record (Tag No. 0)” on page 25).

The certification status may be lost in the following circumstances:

• A new IFD public key is loaded by a PK_Send command

• An error occurs during execution of a PK_Verify command (in “Verify Certificate” mode)

The certification process (performed by a PK_Verify command in “Verify Certificate” mode) is as follows:

Compare Result with IFD public key.

If they are equal, the certificate is verified, and the certification status associated witIFD keys is set to 1.

Certificate = Sign (IFD public key)[PrKCa]

Result = Verify (Certificate) [PuKCa]

© GEMPLUS 2000


Figure 38 - Public Key Certification

Where:

PrK_Ca is the Authority’s private key.

PuK_Ca is the Authority’s public key.

PuKIFD is the IFD public key.

PrKIFD is the IFD private key.

Cert_IFD

Data

PKVerify in Verify Certificate mode

mod (N) and exp (v) are validated and may be usedV is sent by the card

V

described by means oftemplates

ICC

PuK_Ca

computes HH=hash(Cert_data)

If OK, certification status is set in

computes VV=verify(Cert_IFD)[PuK_Ca]

compares V&H for RSA

EEprom in Tag0 of the SFI_IFDfile

compares V&R for DSA

IFD

using PKSendSends the PK set of Key (mod, exp)

Verify the certificate Cert_IFDwith the PuK_Ca using

Cert IFD

PuKIFD, PrKIFD,

mod (N) and exp (v) are writtenin a SFI_IFD file

SFI_CA file is selected+hash algo+verify algo

Select Crypto Context

Select a Verify certificate contextwith the specified algorithms using

Where Cert_IFD=sign (hash(Cert_Data))[PrK_Ca]is stored in IFD applicative database.

Cert_data= ( Id//Data//reverse N//reverseV)

Put data to be hashed for comparison forexample, Data||reference to PK elementsin the PK file of the card usingPut Crypto Data

Caution: The PK element of a certificate ({n,v} for RSA, {p,q,g,y} for DSA) (see “Note on DSA” on page 4) must be signed in reverse order:

For example:

Certificate = sign(hash(cert_data / reverse n/ reverse v))[PrKCa]

Caution: The Authority public key PuK_Ca is loaded once only in the card during the personalization phase. Therefore, the PuK_Ca file is locked for updating and writing, and the PuK_Ca system record, Tag0, (see “The System Record (Tag No. 0)” on page 25) must be created using the Append Record command with the certification status set to 1.

© GEMPLUS 2000


Data Deciphering: Unwrapping Using RSAIn new S/MIME-compatible e-mail applications, messages are exchanged within digital envelopes. These envelopes consist of two parts: an ordinary slot including data ciphered with a symmetric key, and an additional slot including this symmetric key ciphered using the RSA public key of the receiver.

The opening of the envelope and the extraction of the data is performed by a command: PK_OpenEnvelope. The format of the RSA encryption block must be compliant with one of the following:

• PKCS#1

• ANSI X9.31

• ISO 9796-2

Three versions of this feature exist:

• One for unwrapping keys up to 56 bits

• One for unwrapping keys up to 512 bits

• One for unwrapping keys up to 1,024 bits

See “Legal Restrictions” on page 4.

Two steps are involved when deciphering:

1. Context selection (Select Crypto Context command)

2. Unwrapping (PK_OpenEnvelope command)

Public Key CommandsPublic keys can be used for authentication purposes by signing data (private key elements) and verifying the certificates (public key elements). Although no actual PK Ext Aut command exists in GPK, the card can authenticate an IFD by checking an IFD signature based on data known by the card, and computed with the IFD PK (private key). The PK_Verify command could be used to check the signature.

PK Internal AuthenticateThis mechanism allows the card, and the card-holder to be authenticated by the IFD. For this authentication, the card receives a random number, and hashes it using either the MD5 or SHA function to process an RSA, DSA (see “Note on DSA” on page 4) or SSL computation. The card then signs the result with the card private key and returns it as a cryptogram to the IFD.

This cryptogram is then verified by the IFD using the same algorithm, the random and the card public key known and certified by the terminal.

Note: 512-bit, 768-bit, 1,024-bit RSA keys can be used to unwrap.

© GEMPLUS 2000


or

to

Process Example:

PuKCard and PrKCard are the set of public keys of the issuer, for example a card holder.

Figure 39 - PK Internal Authentication

PK SignatureData can be signed by DSA or RSA keys, see “Note on DSA” on page 4.

DSA AlgorithmFor DSA, the standard NIST FIPS PUB 186 (May, 1996) algorithm is used.

The data to be signed is hashed using the SHA hash function and then directly signed using the DSA algorithm and private key elements.

RSA AlgorithmThe PK signature is always done on compressed data.

Three modes are supported by the card to compute this compressed data:

• Using MD5 + padding

• Using SHA + padding

• Using SSL standard

Data to be signed must be the same size as the PK Modulus, N (512 bits, 768 bits, 1,024 bits, depending on the PK file type).

The padding is used to expand the compressed data to this Modulus Length.

Terminal or IFD Card

TRnd

TRnd= Terminal Random Number

S= sign ( TRnd || [PrKIcc] )

V= Verify( S)[PuKIcc]S

C= compare(V&TRnd)If equal, Card is authentic for the IFD

Note: In GPK, there is no Card Random Number (CRnd) to concatenate to the databe signed.

Note: No padding is necessary to sign the hashed data in this algorithm.

© GEMPLUS 2000


of

m ach

st

This standard defines an Encryption Block EB as:

The Block EB to be encrypted or signed consists of a block type BT, a padding string PS, and the data D.

EB = 00|| BT || PS || 00|| D

Where:

MD5 Mode

The specific MD5 header is coded following ASN1 recommendations, in DER coding (TLV format).

Tag values are:

• 30h for the Sequence_Tag.

• 04h for the hash algorithm.

The header is 18 bytes long and is implemented as follows (all values are in hex):

This header is followed by the 16 bytes of the hash algorithm.

The | N | sized message is as follows:

EB is n bytes, where n is the length of the RSA-key modulus in bytes.

The leading 00h guarantees that the length of EB will be less than the lengthmodulus. (All numbers are written in hexadecimal).

BT 01 for a digital signature and the padding consists of blocks of FFh.

02 for encryption and the padding string consists of random or pseudo-randonon-zero bytes. These padding bytes must be unpredictable and unique to emessage.

PS the padding string is (n-3-[length(D)]) bytes long. This value should be at leaeight bytes to provide security against attacks. This leads to a data length limitation when the block length is limited by the card reception capabilities.

D for digital signatures it is BER encoded:

D = BER-encoded(Digest Info)

where Digest Info is either MD5_hash or SHA_hash.

Tag Lng Tag Lng VALUE Tag Lng

30 20 30 0C 06 08 2A 86 48 86 F7 0D 02 05 05 00 04 10

First byte BT byte [ |N|-(3+34) ] PS bytes 1 byte 18 bytes 16 bytes

00h 01h FFhFFh...FFhFFh 00h MD5Header Hashed Data

© GEMPLUS 2000


http:// http://

KS),

es

l

is

ta

SHA1 Mode

The specific SHA1 header is coded following ASN1 recommendations, in DER coding (TLV format).

Tag values are:

• 30h for the Sequence_Tag.

• 04h for the hash algorithm.

The header is 15 bytes long and is implemented as follows: (all values are in hex)

This header is followed by the 20 bytes of the hash algorithm.

The | N | sized message is as follows:

SSL Mode

Netscape’s Secure Socket Layer protocol version 3.0 (November 1996 available at home.netscape.com/eng/ssl3/) is on the way to becoming an Internet standard (seelists.w3.org/Archives/Public/ietf-tls for progress). The protocol supports server and customer authentication, establishment of a session key, secure messaging (CRYCencryption and compression.

GPK only supports the customer authentication part of the SSL protocol. This includpadding before signature.

For RSA, the SSL specification follows part of the PKCS#1 format, that is, EB is stildefined as:

EB = 00 || BT || PS || 00 || D

However, D is different from the BER-encoded digest info defined in PKCS#1. This the level at which SSL comes into effect.

D = MD5_Hash || SHA_Hash

Tag Lng Tag Lng VALUE Tag Lng

30 21 30 09 06 05 2B 0E 03 02 1A 05 00 04 10

First byte BT byte [ |N|-(3+35) ] PS bytes 1 byte 15 bytes 20 bytes

00h 01h FFhFFh...FFhFFh 00h SHA Header Hashed Da

Caution: For GPK, the hashed data MD5 || SHA are loaded into the card by the InitHashedData PK command. The data must be transmitted in a reverseorder (that is, MSB instead of LSB).

Reverse (Hash_SHA) || Reverse (Hash_MD5)

© GEMPLUS 2000

© GEMPLUS 2000

7
GPK Optional Features
k rface

d. The 9600 d to

rds:

rd g

You can order custom configurations for the following GPK card features:

• Communication speed

• Answer To Reset

• Custom OS extensions

Communication SpeedThe GPK card communication speed is specified using conversion parameters (clocconversion rate F and bit adjustment rate D) and the clock frequency of the Card InteDevice. The conversion parameters F and D are defined by the ISO 7816-3 standardefault GPK card communication parameters implement a communication speed of Baud with the Card Interface Device clock set to 3.68 MHz. These values corresponF = 372 and D = 1 in relation to ISO 7816-3.

These parameters can be changed using either the double reset mechanism or the Switch Speed command.

The Switch Speed CommandThe Switch Speed command enables you to specify the communication speed.

For instance, if your Card Interface Device has an internal clock of 3.68 MHz (for example, GemPC410 reader), the following baud rates can be specified for GPK ca

• 9600 Baud

• 57600 Baud

• 115200 Baud

Caution: These custom configurations are implemented by Gemplus during the capersonalization. You must specify all custom configurations when orderinyour GPK cards.

74 GPK Optional Features

m

.

The Double Reset MechanismIf you need to use two different communication speeds for different phases of your application, you can specify one speed that will be used after the Answer To Reset sequence and another speed that will be used after a double reset (without powering off the card). The first reset is called a “Cold Reset”. The second reset is called a “WarReset”.

The Answer To Reset returns the TA1 parameter that specifies the current card communications rate, so that the Card Interface Device can adjust itself accordingly

If you want to implement a double reset mechanism please liaise with your nearest Gemplus technical consultant.

Communication ProtocolsGPK cards run under the ISO 7816-3 T = 0 protocol by default. No other protocol isavailable for GPK.

Answer To ResetThe standard GPK Answer To Reset is described in “Appendix A - The Default Answer To Reset”. It is an ISO 7816-4 compatible sequence. Additional information can be obtained by sending the Get Response command immediately after the Answer To Reset sequence.

If you selected custom communication speed, Gemplus can change the card interface parameters (see above).

Gemplus can also add customized historical bytes to suit specific issuer requirements.

Custom OS ExtensionsGemplus can develop and add custom OS extensions to satisfy specific issuer requirements. These are loaded as an application filter to the GPK card.

Caution: If you require any of the following features:

• Double Reset mechanism

• Specific Answer To Reset

• Custom OS extensions

You must order cards with the “customized” option.

“Standard” cards do not offer these facilities.

© GEMPLUS 2000

© GEMPLUS 2000

8
Onboard Key Generation
This feature enables GPK cards to generate RSA keys in CRT mode inside the card. The length of these keys can be either 512 bits or 1,024 bits.

Generate RSA KeyThe command to use to generate the keys is Generate RSA Key. See the “ Generate RSA Key” on page 163 for further details.

Status Byte ValuesThe status bytes that may be returned from the Generate RSA Key are as follows:

90 00h Command successfully executed

62 84h File descriptor error

65 81h Integrity problem on tag0

67 00h Incorrect length

69 81h Tag0 incompatible with the key type to be generated

69 82h Access conditions not fulfilled

6A 82h File not found. File is not a PK file. Private portion has not been created.

6A 84h Not enough memory space in the file

6B 00h Incorrect P2

76 Onboard Key Generation

he d 67 the K,

b7 of

e.

Retrieving the Public Key PortionAfter the key set generation, use the Get Response command to retrieve the public portion of the generated key preceded by the status words:

Where:

The status bytes that may be returned from the Get Response command are as follows:

The two first bytes returned by the Get Response command give the information if the two prime numbers (P and Q) have been successfully generated in the allowed time.

Conditions of Use and SecurityThe Generate RSA Key command generates a key which is stored in an EF key file that has already been created. In order to store the generated key, it is necessary to satisfy the access conditions for that key file, both Group 1 (Update) and Group 2 (Append).

The Generate RSA Key command fails if the key file is protected by a key. This is because protecting a file by a key means that commands accessing that file must use secure messaging (CLA = 84h). The Generate RSA Key command has a class byte of 80h.

To prevent this, make sure that the key file that is to be used to store the generated keys, is not protected by a key for either Group 1 or Group 2.

Remarks• The command generates private and public keys:

− Private portion: P, Q, Q-1modP, Dmod(P-1), Dmod(Q-1)

− Public portion: V the public exponent is known and written. For GPK16000 tuser can specify a public exponent. This must be prime and must not exceebytes (536 bits). If the public exponent does not exist in the public portion ofpublic key file, the default value of 10001h is used. For older versions of GPthe public exponent is always 10001h. The public key modulus, N = P*Q.

• The command saves the public modulus and the public exponent if mandatory (P1 = 1). In all cases private elements are saved in the private key file.

CLA INS P1 P2 Le

00h C0h 00h 00h Le

Le is the length of the generated key, preceded by the status return bytes asfollows:

42h 512-bit key generated

82h 1,024-bit key generated

90 00h Successful Generation (Public Key portion 40h or 80h)

65 81h Memory failure

6C Licc Incorrect length (new attempt possible). Licc is the length of data availabl

© GEMPLUS 2000

Onboard Key Generation 77

00,

69

+

es

• For a 1,024-bit key, the OS builds a record for each element CRT element (TAGElement) then writes in EEPROM.

• In GPK16000, an alternative method of generating RSA keys is available. This method is compliant with the X9.31 standard.

Key File StructureThe structure of public key files in the card is shown in “Public Key Files” on page 24.

Records in the file are saved in the following format:

The elements for the generated keys are as follows:

Key File for a 1,024-bit Key

• Public Portion:

Table 16 - Public Portion for a 1,024-Bit Key

The total size of the public portion of the key file (1,024 bits) is 8 + 5 + 130 = 143 bytes (8Fh).

The previous example assumes the default public exponent of 10001h. For GPK160the exponent can be defined (the tag is still 07h), but must always be:

• No more than 67 bytes.

• No longer than the modulus.

In this case, the length of the exponent, plus system byte + tag could be as much asbytes.

This would make the total size of the public portion of the key file (1,024 bits) 8 + 69130 = 207 (CFh) bytes.

Lsys Tag Body

- The record length -

One byte

- The tag value -

One byte

- A key element -

(Lsys value – 1) bytes

Lsys Tag Body

07h 00h System record

04h 07h Public exponent (default value is 10001h)

81h 01h Public modulus

− Descriptor System Byte + TAG0 + Body = 8 bytes

− Public exponent System Byte +Tag + Body = 1 +1 + 3 = 5 bytes

− Public element: System Byte + Tag + Body = 1 + 1+ 128 bytes = 130 byt

© GEMPLUS 2000

78 Onboard Key Generation

00,

64

+

/2)

• Private Portion:

Table 17 - Private Portion for a 1,024-Bit Key

The total size of the private portion of the key file (1,024 bits) is 8 + (5*67) = 343 bytes. However, the total size must be a multiple of four, so the total becomes 344 bytes (158h) (56h in words).

Key File for a 512-bit Key

• Public Portion:

Table 18 - Public Portion for a 512-Bit Key

The total size of the public portion of the key file (512 bits) is 8 + 5 + 66 = 79 bytes (4Fh).

The previous example assumes the default public exponent of 10001h. For GPK160the exponent can be defined, but must always be:

• No more than 67 bytes.

• No longer than the modulus.

In this case, the length of the exponent, plus system byte + tag could be as much asbytes (the same size as the modulus).

This would make the total size of the public portion of the key file (1,024 bits) 8 + 6666 = 140 (8Ch) bytes.

Lsys Tag Body


42h 51h Prime 1 : Lg || P

42h 52h Prime 2 : Lg || Q

42h 53h Lg || Q-1 mod P

42h 54h Lg || s mod(P-1)

42h 55h Lg || s mod(Q-1)

• System Byte + Tag0 + Body = 8 bytes.

• Five private elements are formed by: System Byte +Tag + Element size + (N= 1 + 1 +1 + 64 = 67 bytes (per element).

Lsys Tag Body


04h 07h Public exponent = 10001 Hex (default value)

41h 01h Public modulus

• Descriptor System Byte + TAG0 + Body = 8 bytes

• Public exponent System Byte +Tag + Body = 1 +1 + 3 = 5 bytes

• Public element: System Byte + Tag + Body = 1 + 1+ 64 bytes = 66 bytes

© GEMPLUS 2000

Onboard Key Generation 79

key

• Private portion:

Table 19 - Private Portion for a 512-Bit Key

This first record, seven bytes long, identified with Tag_Nb “0” describes the set ofcharacteristics.

For details on the coding of the system record, see “Public Key Files” on page 24.

Lsys Tag Body


A6h 05h Lg || P, Lg || Q, Lg || Q-1 mod P, Lg || s mod(P-1), Lg || s mod(Q-1).

− System Byte + Tag0 + Body = 8 bytes

− Five private elements are stored in the same record

This record size is therefore System Byte + Tag + Element size.

Each element is made up of a length byte and its value.

The record size is therefore, 1 + 1 + 5 * (1 + N/2).

This equals 1 + 1 + 5 * (1 + 32) = 167 bytes.

This number is not a multiple of 4, so the OS must reserve 168 bytes.

Total size of private key file (512 bits) is : 8 + 168 = 176 bytes

Note: The system record must be the first record written to the file. This means it is physically loaded just after the file descriptor.

© GEMPLUS 2000

© GEMPLUS 2000

9
The Unwrap Feature
This feature enables the GPK cards to unwrap (decrypt) a session key which has been encrypted with the RSA algorithm.

Command SequenceIt operates as follows:

1. Select an RSA key using the SelectCryptoContext command (P2 = 77h).

2. Unwrap (decrypt) this session key using the PK_OpenEnvelope command. The input data must be given LSB first. The decrypted data is returned LSB first.

3. Extract the data using the Get Response command.

For further details on the use of these three commands, see the individual command descriptions in “Chapter 13 - Public Key Cryptography Commands”.

Status Byte ValuesThe status bytes that may be returned from the SelectCryptoContext command are as follows:

62 84h Header integrity error

64 00h Wrong context

65 81h Tag0 integrity error

69 82h Security status not satisfied

69 85h Conditions of use not satisfied / Max session key < Extracted data length

6A 80h Padding error (PKCS#1)

6A 81h Invalid file

6A 82h File not found

6A 83h Tag not found

6B 00h Incorrect Padding

82 The Unwrap Feature

ard

or

al to

using

1

the

The status bytes that may be returned from the PK_OpenEnvelope are as follows:

Once the key has been unwrapped, the card transmits it to the application in plain text.

A specific EF is created during the initialization process. It holds a one-byte variable: MaxSessionKey. This is the maximum length – in bytes – of the session key that the cis able to unwrap (or decrypt). This restriction is needed to comply with legal considerations.

To be able to use the raw format, the value of MaxSessionKey must be greater thanequal to the modulus length of the selected PK file.

The length of an extracted session key must be less than or equal to the value of MaxSessionKey. However, the only limit for the envelope size is that it must be equthe modulus length of the selected PK file.

The value of 00h for MaxSessionKey deactivates the PK_OpenEnvelope command.

The file containing MaxSessionKey is:

• located under the SYSTEM DF (01 00)

• a transparent EF (FDB = 01h)

• has a body size of one byte

• has a file number of 01 FF

• locked for writing and updating

• can be read freely

Retrieving the Decrypted DataIf the decryption was successful and the length of the data to be returned is ≤ MaxSessionKey, this data is copied (LSB first) to the response area, and its lengthstored in the expected length counter. This way, the user can get the decrypted dataa Get Response command as follows.

Where:

Le is the length of the decrypted data. For a raw envelope, this is 80h. For a PKCS#envelope it can be any value up to and including the Max Session Key.

Context Modification After ExecutionExecuting the PK_OpenEnvelope command clears the context byte, so a new cryptographic context will be required.

61 xxh Command successfully executed (xx is the length of data available for Get Response command.

69 85h No data available for Get Response command.

CLASS INS P1 P2 Le

00h C0h 00h 00h Le

© GEMPLUS 2000

© GEMPLUS 2000

10
Command Format
GPK cards accept commands and responses in compliance with the Application Data Protocol (APDU) format defined by the ISO 7816-4 standard. This enables GPK commands to be compatible with the Gemplus GemPC readers. You should bear in mind, however that the GPK transmission layer protocol complies with the ISO 7816-3 T = 0 standard, which converts APDUs into Transmission Protocol Data Units (TPDUs). The reader sends TPDU commands to the card, and the card returns TPDU responses to the reader.

GPK cards accept commands in any of the following cases:

Case 1-no command or response data. This is sent as a T = 0 ISO IN TPDU with length = 0.

Case 2-Short format: no command data, but with between 1 and 256 bytes response data. This is sent as a T = 0 ISO OUT TPDU.

Case 3-Short format: command data between 1 and 255 bytes and no response data. This is sent as a T = 0 ISO IN TPDU.

Case 4-Short format: command data between 1 and 255 bytes, response data between 1 and 256 bytes. The command is sent as a T = 0 ISO IN TPDU. It must be followed by a Get Response command sent as a T = 0 ISO OUT TPDU. The Get Response mechanism is compliant with the ISO 7816-4 standard.

These cases are referred to as 1, 2S, 3S, and 4S respectively. GPK does not accept commands in any other format, and responds with the status 67 00h.

Command FormatGPK cards accept commands in the following format:

Header Body

CLA INS P1 P2 Lc Parameters/Data Le

84 Command Format

Header FieldsThe header fields are mandatory, and are as follows:

Body FieldsThe command body is optional. It includes the following fields:

Response FormatGPK cards return responses to commands in the following format:

The body is optional and holds the data returned by the card.

The Trailer includes the following two mandatory bytes:

• SW1: Status byte 1 that returns the command processing status

• SW2: Status byte 2 that returns the command processing qualification

See “Appendix B - Card Return Codes” for a list of the values that GPK cards can return in the status bytes.

Field Name

Length Description

CLA 1 byte Instruction class. This can be any of the following values:

00h ISO 7816-4/EMV compatible command

04h ISO 7816-4/EMV compatible command with secure messaging

80h Proprietary command

84h Proprietary command with secure messaging

INS 1 byte Instruction code. This is given with the command descriptions.

P1 1 byte Parameter 1

P2 1 byte Parameter 2

Field Name

Length Description

Lc 1 byte Data length

Command parameters or data

Expected length of data to be returned

Data n bytes

Le 1 byte

Body Trailer

Data SW1, SW2

Note: In the following sections (commands description), commands are described in TPDU format (T = 0) only, according to the default card protocol.

© GEMPLUS 2000

© GEMPLUS 2000

11
Administration Commands
This chapter gives a comprehensive description of the administration commands. These include ISO commands, plus a complementary set of non-ISO defined commands that perform administrative tasks (for example, file creation). The following table gives a brief summary of these commands.

The GPK administration commands are listed in alphabetical order.

These commands constitute the kernel of GPK.

Cmd. Full Name Description

ApdRec Append Record Appends a new record to a structured file.

CrtFile Create File Creates an Elementary File (EF) or a Dedicated File (DF).

ExtAut External Authenticate

Causes the card to check a cryptogram sent from the outside world.

FreezeAC Freeze Access Conditions

Locks or localizes a file access condition.

GetChal Get Challenge Generates an 8-byte or 32-byte random number.

GetInfo Get Info Retrieves miscellaneous information (about the card and files, for example).

GetResp Get Response Retrieves and erases the data prepared in RAM by the card in response to the previous command.

IntAut Internal Authenticate

Causes the card to compute a cryptogram for verification by the outside world.

RdBin Read Binary Reads data from transparent EFs.

RdRec Read Record Reads data from a structured file.

SelFil Select File Selects an EF or a DF for use in transactions.

SelFk Select File Key Computes a temporary administration key, and an authentication cryptogram.

Table 20 - Administration Commands

86 Administration Commands

Where:

SetCard Status

Set Card Status Sets the personalization flag to 1 once card personalization has been completed and sets the size of the data units.

SetCod Set Secret Code Unblocks or changes a secret code.

SwtSpd Switch Speed Switches the card to another speed.

UpdBin Update Binary Updates data in an EF.

UpdRec Update Record Updates data in a structured file.

Verify Verify Compares the value submitted to the secret code number (0 to 7) in the secret code file pertaining to the currently selected DF.

WrBin Write Binary Writes data to an EF by performing a logical OR operation between the current value of the write area and the value being written.

Cmd. is an abbreviation of the command name.

Full Name specifies the command name.

Description offers a brief description of the command function.

Table 20 - Administration Commands

© GEMPLUS 2000

Administration Commands 87

Append Record

This command is used to format a structured file by appending (and initializing) a new record. See “Structured Files” on page 15.

Selection of the file to be appended can be direct or implicit. When direct selection is used, the file must have been previously selected using the Select File command. For implicit selection, the file is selected in the current Dedicated File (DF), using the Short File Identifier (SFI). If the selection is successful, the selected file becomes the current file and the record pointer is cleared.

Secure MessagingThis command can use secure messaging, as long as the length of the record plus that of the certificate does not exceed the internal buffer size (see “IO Buffer Size” on page 43). For further information on the conditions that must be met before secure messaging can be used, see “Secure Messaging” on page 59.

File TypeThis command can only be executed on structured Elementary Files (EFs).

Note: For cyclic files, a new record can only be created if the current record corresponds to the last created (appended) record. If a new record is created (in normal processing), this record becomes the current record and the record pointer is set accordingly.

The Append Record command does not cycle, that is, after appending the last record in the file, the command can no longer be used.

Caution: If an Update Record command has been performed since the last Append Record command, the current record is no longer the last created record. See the example in “Cyclic Files” on page 17.

© GEMPLUS 2000


Format

Where:

Response

Where:

CLA INS P1 P2 Lc Data

CLA E2h P1 P2 Lc Data

CLA Specifies transmission mode (normal or secure messaging):

00h Transmit normally.

04h Transmit with secure messaging.

P1, P2 P1 is set to zeroes. P2 specifies (by its SFI) the file to which the record is to be appended. In the case of direct selection, the file will have been previously selected using the Select File command and the SFI is set to zero.

Lc Specifies the length of the record, which is to be appended. If secure messaging is being used, a value of 03h should be added.

Data Data to be written to the appended record.

� �

3�

� � � � � �

3�

6), � � �

CRYCKS 7-5 SW1 SW2

CRYCKS is the cryptographic response generated by the card if secure messaging was used (see “Secure Messaging” on page 59). The terminal can retrieve the three MSB of this checksum by executing the Get Response command (see “ Get Response” on page 103).

SW1 and SW2 hold the status byte values returned by the card. “Appendix B - Card Return Codes” lists the possible contents of SW1 and SW2.

© GEMPLUS 2000


Create File

Creates an Elementary File (EF) or a Dedicated File (DF).

The access condition that governs file creation, is in the file descriptor of the current DF (or the Master File (MF)). The Group 1 access condition applies if it is a sensitive file, the Group 2 access condition applies if it is a data file. The access condition contains a Short File Identifier (SFI) (see “Access Conditions” on page 46). If this SFI is zero, normal processing is used, otherwise secure messaging is used. In normal mode, the only data that is sent to the card is the data needed to initialize the descriptor (12 bytes), plus (if creating a DF) a name of no more than 16 additional bytes.

Secure MessagingFor more details about the conditions that must be met before secure messaging can be used, see “Secure Messaging” on page 59.

The data sent to the card is the same as for normal processing (described here) in clear text plus an additional cryptographic checksum of three bytes. This checksum is calculated using the data field plus the command header.

When the card receives the command, it verifies that the cryptographic checksum matches the command and data. If they do not match, the card denies access to the command and returns an appropriate error code. If they do match, the card creates the file, provided that no other errors are detected.

File TypeThis command is for both DFs and EFs.

Format

Where:


CLA E0h Ftype 00h Lc Data


80h Transmit normally

84h Transmit with secure messaging

Ftype Specifies the type of file to create, as follows:

01h DF

02h EF

© GEMPLUS 2000


Creating a DFTo create a dedicated file, the data field is as follows:

Lc Specifies the length of data sent with the command, in bytes:

12 to 28 (0Ch to 1Ch)

Create a DF. A value of 03h should be added if secure messaging is used.

12 Create an EF. A value of 03h should be added if secure messaging is used.

Data Holds the data field sent to the card. The format and contents of this data depend on the file type being created: DF or EF.

File Identifier Holds a two-byte file identifier. The SFI corresponds to the five lsb. Under ISO 7816-4, the MF has the identifier 3F00h.

FDB Holds the File Descriptor Byte, which determines the type of file and associated options. This must hold the following value:

OPT Holds the file option byte. This is as follows:

*URXS��$&

)LOH�,GHQWLILHU )'% 237 1DPH�/HQJWK *URXS��$&

')�1DPH��±��E\WHV�5)8

Bit 7 6 5 4 3 2 1 0

0 0 1 1 1 0 0 0

Bit 7 6 5 4 3 2 1 0

CanDeb

RFUCurBal

RFURFURFURFUEA

© GEMPLUS 2000


ts

The following table shows the options indicated by each bit:

Cryptographic checksum if secure messaging is used. See “Chapter 4 - Access Conditions”.

Creating an EF

To create an EF, the data field is as follows:

Bit Value Option Indicated

0 Not used.

1 1 Cancel Debit command disabled.

0 Cancel Debit command enabled.

2 1 Current balance can be used to compute signature certificates, provided that this option is not reversed using the Set Options command (see “ Set Options” on page 153).

0 Current balance can never be used to compute signature certificates (see “ Sign” on page 155).

3–6 RFU

7 1 Select Purse & Key and Select File Key commands depend on an external authentication.

0 Select Purse & Key and Select File Key commands are free.

Table 21 - Options Byte Values

File Identifier Holds a two-byte file identifier. The SFI corresponds to the contenof the five least significant bits.

FDB Holds the File Descriptor Byte. This takes the following format:

Bits 5 to 3 Define the EF type, for example, Key EF.

Bits 2 to 0 Specify the structure of the file for example, cyclic.

For a list of values for bits 5–0, see “File Descriptor” on page 11.

*URXS��$&

)LOH�,GHQWLILHU )'% 5HF/HQ %RG\�6L]H *URXS��$&

$GGLWLRQDO�'DWD*URXS��$&

� � ; ; ; ; ; ;

� � � � � � � �%LW

© GEMPLUS 2000


Response

Where:

RecLen Specifies the record length for linear fixed and cyclic files only. It is not valid for other EFs and is normally set to zero.

Body Size Specifies the file body length in bytes. For EFs, the body corresponds to the data constituting the file.

Groups 1, 2, 3 AC hold the access conditions for Groups 1, 2, and 3 respectively. The first byte of each access condition is the Group AC. This is stored in the fixed part of the file descriptor. The second byte is the AC Secret Code Reference. This is stored in the variable part of the file descriptor. See “Chapter 4 - Access Conditions” for more details about access conditions. For details on how the access conditions are stored, see “File Descriptor” on page 11.

Cryptographic checksum if secure messaging is used.

CRYCKS 7-5 SW1 SW2



© GEMPLUS 2000


el

External Authenticate

This command is the 3DES-based method of authenticating the outside world to the card.

The external world (that is, the terminal) must have retrieved an eight-byte random value from the card using a Get Challenge command prior to the external authentication. The terminal calculates the External Authentication Cryptogram (EAC) using the random value and an authentication key. The terminal then sends the random value, the reference for the authentication key and bytes 7-4 of the EAC it calculated to the card. The card calculates its own cryptogram and compares it with the EAC to verify whether the EAC is consistent or not.

Only authentication key types can be used by this command.

Authentication rights are lost after:

• Card reset

• Failed authentication

• DF selection (unless from the MF)

Format

Where:

Note: GPK allows the use of the Select Purse & Key/Select File Key commands to be linked to correct external authentication. If the correct option is set at card lev(see “OPT” on page 10), then it will not be possible to compute a temporary certification key if the card has not authenticated the external world. More details are provided in the Select Purse & Key/Select File Key command descriptions and the options byte description.


00h 82h 00h P2 06h Data

P2 is coded as follows:

L XX X X X X X

Where: L = 0 Key used is at global level.

L = 1 Key used is at local level.

© GEMPLUS 2000


(see

Command Processing1. The key references are transmitted to the card as part of the data field.

2. The cryptogram is calculated by the outside world as follows:EAC = 3DES (CRnd,Kaut)

3. GPK verifies that a random number is available (see “ Get Challenge” on page 99).

4. GPK temporarily selects and checks the external authentication key.

5. GPK computes the mirror cryptogram EAC’ = 3DES(CRnd, Kaut).

6. GPK compares EAC’ with EAC.

7. If the authentication has been successful then, depending on the DF option byte“File Descriptor” on page 6), the Select Purse & Key/Select File Key command can be used.

The following figure summarizes the External Authenticate command processing:

.

Figure 40 - External Authenticate Command Processing

Where:

Data is coded as follows:

Kn is the number of the specified external authentication key, coded as follows:

Kf is the Short File Identifier (SFI) of the file holding the external authentication key.

EACi External Authentication Cryptogram (EAC) bytes 7 to 4.

Kn Kf EAC7 EAC6 EAC5 EAC4

Bit 7 6 5 4 3 2 1 0

Key Number 0

Kaut is the authentication key selected for EAC generation

CRnd is the Random value generated by the previous Get Challenge command.

GPK Card

External Authenticate(Kn, Kf, EAC[7-4])

Terminal

Computes EAC' = 3DES (CRnd, Kaut)Verifies that EAC'[7-4] = EAC[7-4]

Verifies that challenge random value is available

Depending on the DF option byte, mayallow/forbid use of SelP&K/SelFk

Clears Aut

© GEMPLUS 2000


Response

Where:

SW1 SW2


© GEMPLUS 2000


,

arent tions

Freeze Access Conditions

Modifies a file access condition. It is used because the original access conditions defined at the time of file creation may need to be changed for the application phase. This command can work in one of two modes: Lock mode or Localize mode.

If the command is executed in Lock mode, it locks an access condition so that it denies access at all times. This mode might be used to make a file read-only after personalization.

If the command is executed in Localize mode, it moves the key or secret code references from the Master File (MF) EFKey and EFsc files to the parent Dedicated File (DF) EFKey and EFsc files. Once this has been done, you cannot perform another Freeze AC command on the same file except in Lock mode. This mode is useful for initializing an application.

To freeze the access conditions of DFs or the MF make sure that:

• The MF is currently selected

• The Group 1 access conditions of the MF are satisfied

To freeze the access conditions of EFs make sure that:

• The file whose access conditions are to be frozen is in the currently selected DF

• To freeze sensitive file access conditions, the Group 1 access conditions of its pDF are fulfilled. To freeze data file access conditions, the Group 2 access condiof its parent DF are fulfilled.

For further information, see “Chapter 4 - Access Conditions”.

If the key file indicator in the Freeze AC (freeze data files or freeze sensitive files) contains a value other than zero, then the command must be sent with secure messaging (see following paragraph). Otherwise the data received by the card will merely be the five-byte data field as described on the following page.

Secure MessagingFor more details about the conditions that must be met before secure messaging can be used, see “Secure Messaging” on page 59.

In secure messaging mode, the card receives the data in the same way as for normal processing but an additional three-byte cryptographic checksum is sent.

When the card receives the command, it verifies that the cryptographic checksum matches the command and data. If they do not match, the command is rejected and the card returns an appropriate error code.

File TypeThis command can be executed on any type of file.

Note: To localize access conditions, the EFKey and EFsc files that they refer to must exist locally and contain the required keys and secret codes. If not, the localized access condition may become locked.

© GEMPLUS 2000


Format

Where:

Where:


CLA 16h Mode 00h Lc Data




Mode Specifies the type of file to freeze, as follows:

01h DF or MF

02h EF

Lc Specifies the data field length, in bytes:

05h Command sent in normal mode.

08h Command sent using secure messaging.

Data Specifies the file identifier and access condition modifications to be made. It has the following structure:

Identifier Specifies the identifier of the file to be frozen.

G1, G2, G3 Are the control bytes for the Group 1, Group 2, and Group 3 access conditions. They describe how each access condition can be modified.

Each control byte has the following format:

L K SC1 SC2

The following table shows how the control byte contents modify their related access conditions (the values in the following table are in binary):

L K SC1 SC2 Modification

01 XX XX XX Locks access condition

00 00 XX XX No change to secure messaging key

00 01 XX XX Localize secure messaging key

00 XX 00 XX No change to secret code 1

00 XX 01 XX Localize secret code 1

00 XX XX 00 No change to secret code 2

00 XX XX 01 Localize secret code 2

Table 22 - Control Byte and the Related Access Conditions

Identifier G1 G2 G3

© GEMPLUS 2000


Response

Where:

CRYCKS 7-5 SW1 SW2



© GEMPLUS 2000


Get Challenge

This command is used to generate either an 8-byte random number to be used in DES based crypto-applications or a 32-byte random number which may be useful for public key crypto-applications. This random number is sent to the outside world in order to be ciphered by the terminal, and is kept in RAM for later verification (see “ External Authenticate” on page 93).

The number is lost under the following circumstances:

• Card reset

• Unsuccessful Get Challenge command

• Following an External Authenticate command (whether successful or not)

• Selection of a DF (including the MF)

Format

Where:

Response

Where:

CLA INS P1 P2 Le

CLA 84h RFU RFU Le

CLA is the instruction class byte

00h generate an 8-byte random number

80h generate a 32-byte random number

Le is the length of the random number to be generated

08h for an 8-byte random number

20h for a 32-byte random number

Rnd SW1 SW2

Rnd An 8-byte or 32-byte random number.


© GEMPLUS 2000


Get Info

Retrieves card-related information. This data can be:

• Data generated by the card in response to a command

• Generic system data

• Application data

File TypeThis command can be executed on any type of file.

Format

Where:

CLA INS P1 P2 Le

80h C0h P1 P2 Le

P1, P2 Specify the data to be retrieved.

Le is the length of the data to be retrieved.

For values of P1, P2 and Le, refer to “Table 23 - Values of P1 and P2 for the Get Info Command” on page 101.

© GEMPLUS 2000


P1 P2 Data Retrieved File Type Data Length (Le)

00h 00h Data prepared in the RAM in response to the previous command. For more details about how the command operates in this mode see “ Get Response” on page 103.

—

02h A0h Chip Serial Number 8 bytes

A1h Card Serial Number 8 bytes

A2h Issuer Serial Number 8 bytes

A3h Issuer Reference Number 4 bytes

A4h The following pre-issuing data:

Family Name (FMN) *

Product Name (PRN) *

OS Version (OSV) *

Program Version (PRV) *

Chip Identification Value (CIV) *

Gemplus Issuer Reference

SECU byte

TPRG byte

LOCK1 byte

LOCK2 byte = LOCK1 byte

1

1

1

1

1

4

1

1

1

1

05h The following application data for the currently selected dedicated file:

Mode/MPN SCR 00h/UCR CKS EFsc No. Secret Codes *4

for each secret code (See “Secret Code Files” on page 33).

Key Type 00h Kv 00h EFkey No. keys *4

Purse Maximum Balance, Credit key file reference, Maximum Free Debit, Access Cd and Cb of the purse.

EFPurse 8 bytes

If the purse is enhanced: the 8-byte purse info, described above, plus additional word, Fsc file level (L) and Credit Access Condition (CAC). See “Enhanced Purse Files” on page 21.

(8 + 4) bytes

06h Descriptor address of the last selected EF or DF.

2 bytes

* See “Table 23 - Values of P1 and P2 for the Get Info Command” on page 101.LOCK1: Complement of LOCK1All other values of P1 and P2 are reserved for future use.

Table 23 - Values of P1 and P2 for the Get Info Command

© GEMPLUS 2000


The product identification values are shown in the following table:

The FMN and PRN can be used to identify a card as GPK regardless of the EEPROM size, O/S version or chip type.

Response

Where:

Note: LOCK1 byte in the table above is the Lock Byte. See “Lock Byte” on page 44 for details on the information it contains.

LOCK2 byte should display the same value as LOCK1 byte. If it displays a different value, then there is a problem and you should contact your Gemplus technical consultant.

If a DF has just been selected, no EF is selected, thus the last selected file is the DF. If an EF is then selected, the last selected file becomes the EF itself.

If application data is retrieved, the Le field value for secret codes and keys must be consistent with the number of keys and secret codes in the selected dedicated file EFsc and EFKey. For example, if an EFKey contains three keys, the data length for the EFKey must be 0Ch (3X4 = 12).

Product Identification Value

FMN (Family Name) A2h (Gemplus generic products)

PRN (Product Name) 08h (GPK 8000)

09h (GPK 16000)

OSV (OS Version) 01h

Program Version (PRV) 01h

Chip Identification Value (CIV)

52h

Gemplus reserves the right to add other CIVs without prior notification.

Table 24 - Product Identification Values

Note: It is not recommended to use the CIV (Chip Identification Value) to identify a card, as this may change if alternative chip suppliers are used.

Response SW1 SW2

Response holds the card response.


© GEMPLUS 2000


e

roach.

Get Response

This command retrieves and erases the data prepared in the RAM by the card in response to the previous command. It can also be issued immediately after the ATR (Answer To Reset). The terminal can send the Get Response command whenever the previous command returns a status byte value of “61 nn”h or “9F nn”h, where nn specifies thresponse length. When the terminal executes the Get Response command, it enters the value nn in its Le parameter. This process enables you to incorporate a transparentresponse return mechanism into GPK applications, that can then use the APDU app

The following table lists the commands that generate responses and describes the response data.

Command Response Length (Le)

Response

SelP&K 8 Computed cryptogram 4 LSB+1 unused byte+3-byte Card Transaction Counter

SelFk 12 Computed cryptogram 4 LSB+8-byte card random number

Debit, CanDeb

2 Card Debit Certificate 2 MSB

RdBal 6 1 unused byte+3-byte balance value+

Card Balance Certificate (2 bytes)

UpdBin, WrBin, CrtFile, FreezeAC, UpdRec, ApdRec

3 Cryptographic checksum 3 MSB if secure messaging is in use

SelFil nn Selected file data (see “Table 26 - Data Returned by Select File Command” on page 104).

IntAut 4 Cryptogram

Table 25 - GPK Command Responses

Note: When the Get Response command is executed, the card erases the response from the RAM, therefore the same response cannot be retrieved more than once.

© GEMPLUS 2000


for

ou d in

Select File

The data generated by the card when it executes Select File depends on the presence (or absence) of the IADF and the type of file selected. For the data format when the IADF is present, see “ Internal Application Data File (IADF)” on page 35. If the IADF is absent,the data is returned in the TLV format. The following table shows the data generatedboth file types:

Table 26 - Data Returned by Select File Command

Answer To Reset

After the ATR, the card returns the descriptor of the implicitly selected MF or DF if yissue a Get Response command. The DF name is not accessible. This data is returnethe TLV format as follows:

Format

Where:

Response

Where:

Tag Length Value Returned After Selecting

85h 10h File Descriptor DF or EF

84h 01h to 10h DF Name DF

Tag Length Value Returned After Selecting

85h 10h File descriptor MF or DF

CLA INS P1 P2 Le

00h C0h 00h 00h Le

Le Specifies the response length (see “Table 25 - GPK Command Responses” on page 103).

Response SW1 SW2

Response holds the card response


© GEMPLUS 2000


,

Internal Authenticate

This command is the 3DES based method of authenticating the card to the outside world.

The external world asks the card to compute an IAC (Internal Authentication Cryptogram). This is computed using a random number sent by the terminal and the internal authentication key held in the card.

The card stores the four LSB of the cryptogram in the RAM, that can be sent to the terminal by a Get Response command. The terminal then compares the result with what it has calculated. See “ Get Response” on page 103.

Only authentication key types can be used by this command.

Format

Where:


00h 88h XXh P2 0Ah Data

P2 is coded as follows:

Data is coded as follows:

Kn is the number of the specified internal authentication keycoded as follows:

Kf The short file identifier of the file holding the internal authentication key.

TRnd Terminal random number.

/ ;; ; ; ; ; ;

L = 0 Key used is at global level.

L = 1 Key used is at local level.

Kn Kf TRnd7TRnd6TRnd5TRnd4TRnd3TRnd2 TRnd1 TRnd0

Key Number 0

Note: See also “ PK_Int Auth” on page 170 for PK based internal authentication.

© GEMPLUS 2000


Command Processing

The key references are transmitted to the card as part of the data field.

GPK temporarily selects and checks the internal authentication key.

GPK computes IAC = 3DES (TRnd, Kaut).

GPK prepares the response.

The following figure summarizes the Internal Authenticate command processing.

Figure 41 - Internal Authenticate Command Processing

Where:

ResponseThe Internal Authenticate command response is retrieved using the Get Response command. The response has the following format:

Where:

IAC Internal Authentication Cryptogram

Kaut Authentication key selected for IAC generation.

TRnd Random value generated by the terminal.

Terminal GPK Card

Internal Authenticate

(Kn, Kf, TRnd)

GetResp

The terminal computes IAC’ and compares it with the card IAC.

Computes IAC = 3DES (TRnd, Kaut)

sends IAC(3–0)

IAC3 IAC2 IAC1 IAC0 SW1 SW2

IAC3 to IAC0 are the four LSB of the IAC.


© GEMPLUS 2000


Read Binary

Reads data from a transparent Elementary File (EF). This command can only be executed if the Group 3 access conditions are fulfilled.

Read Binary can either read from the currently selected EF (direct selection) or select an EF by specifying its Short File Identifier (SFI) and then read from it (implicit selection). In the latter case, this EF becomes the currently selected EF. If the card encounters any errors at this stage, it leaves the selected file as the currently selected file.

There is no limitation on the amount of data that can be read when secure messaging is not being used.


In secure messaging mode, the card returns the data in clear text with a three-byte cryptographic checksum. This checksum uses the data read plus the header of the command.

File TypeThis command can only be executed on transparent EFs.

Format

Where:

Note: 3DES-based cryptography is not used to prevent data from being read, it is only used to guarantee that the data that is being read is from a genuine card.

CLA INS P1 P2 Le

CLA B0h P1 P2 Le




© GEMPLUS 2000


his

ned s

Response

Where:

P1, P2 To read from the currently selected EF, P1 and P2 specify the offset, in words, from the beginning of the file to the first byte to read. Send P1 and P2 in the following format:

To select and read from an EF, P1 specifies the file to be read from using its SFI. P2 specifies the offset, in words, from the beginning of the file to the first byte to read. Send P1 and P2 in the following format:

Le specifies the length of the data, in bytes, to be read. If secure messaging is being used, a value of 03h should be added.

0 Offset (MSB)

P1 P2

Offset (LSB)

1 Short ID

P1 P2

Offset (LSB)0 0

Note: If Le exceeds the amount of available data, or is set to 00h, then GPK returns the status code “6C nn”, where “nn” is the amount of available data.

Data SW1 SW2

Data holds the data returned by the card. If secure messaging is in use, tincludes the three MSB of the checksum.

Note: If secure messaging is used, the maximum number of bytes that can be returin the data field is limited to 61 bytes (buffer size of 64 bytes minus three bytefor the cryptographic checksum).

SW1 and SW2 hold the status byte values returned by the card. ““Appendix B - Card Return Codes” lists the possible contents of SW1 and SW2.

© GEMPLUS 2000


Read Record

This command is used to read data from a structured file.

File selection can be direct or implicit. When direct selection is used, the file will have already been selected using the Select File command. For implicit selection, the file is selected in the current Dedicated File (DF), using the Short File Identifier (SFI). If the selection is successful, the selected file becomes the current file and the record pointer is cleared.

There is no limit to the amount of data that can be read when secure messaging is not being used.


File TypeThis command can only be executed on structured EFs.

Format

Where:

Note: When reading data from cyclic files, the current record always returns the contents of last appended or updated record.

Note: 3DES-based cryptography is not used to prevent data from being read, it is only used to guarantee that the data that is being read is from a genuine card.

CLA INS P1 P2 Le

CLA B2h P1 P2 Le

CLA specifies transmission mode (normal or secure messaging):



P1 is the number of the record to be read. The value zero refers to the current record (this is only allowed for cyclic files).

P2 specifies the file in which the record is to be read by its SFI. In the case of direct selection, the file will have been previously selected using the Select File command and SFI is set to zero.

Record Number

P1 P2

SFI 1 0 0

© GEMPLUS 2000


his

ned s

Response

Where:

Le specifies the expected length of the record that is to be read. If secure messaging is being used, a value of 03h should be added. Le may be less than or equal to the available data length, that is, you can read part of a record.

Note: If Le exceeds the amount of available data, or is set to 00h, then GPK returns the status code “6C nn”, where “nn” is the amount of available data.

Data SW1 SW2

Data holds the data returned by the card. If secure messaging is in use, tincludes the three MSB of the checksum.

Note: If secure messaging is used, the maximum number of bytes that can be returin the data field is limited to 61 bytes (buffer size of 64 bytes minus three bytefor the cryptographic checksum).


© GEMPLUS 2000


00h.

DF), ey

Select File

Selects a Dedicated File (DF) or an Elementary File (EF).

When developing an application you should take into account the effect of file selection on the authorization register:

• At the beginning of a session (after a reset), all authorization registers are set to

• When a file is selected, the card does not clear the MF authorization register.

• When a new DF is selected (even if it is the same file as the previously selectedthe operating system clears the local authorization register and the temporary kstatus.

File TypeThis command can be executed on DFs or EFs.

Format

Where:


00h A4h Type Response Lc File Ref

Type Specifies the selection type, as follows:

00h Implicitly selects the MF or an EF using the File Identifier.

01h Selects a DF when the MF is selected.

02h Selects an EF under the currently selected DF.

04h Selects a DF by its name. This is the DF name stored in thefile body (see “File Body Structure” on page 15).

Response 00h Response required (see the following page).

0Ch No response required.

Lc Specifies the Data field length. This is dependent on the value of the type field. See the following table.

File Ref Specifies the file to select by its file identifier or name. This is dependent on the value of the type field. See the following table:

© GEMPLUS 2000


rieve

e

et

nce

Response

If the IADF is present in the current application, the response depends on the coding and content of the IADF (see “Internal Application Data File (IADF)” on page 35”).

In standard mode (that is, there is no IADF), this response contains the selected filedescriptor and the DF name (if any) if a DF has been selected. The terminal can retthis data by executing the Get Response command.

The data returned in Response is as described:

For DFs:

For more details about these variables, see “Dedicated Files” on page 6.

Type (P2) Lc File Ref (Data)

00h 02h ‘3F 00h’ if selecting the MF, or EF SFI

01h 02h DF identifier

02h 02h EF to select in the currently selected DF. Enter thfile identifier

04h DF name length, from 1 to 16 bytes.

DF name

Table 27 - Select File Type, Lc, and File ID Values

Response SW1 SW2

Fp File Pedigree

Fn File number

File Identifier The five lsb are the SFI

FDB File Descriptor Byte

Opt Options byte. This is the second byte of the “Status/Options” in the variable part of the file descriptor.

DF Name Name of the DF

Group 1 AC Group 1 AC (fixed part of the file descriptor)

AC Secret Code Reference (first – most significant – byte of AC SecrCode Reference in the variable part of the file descriptor).


AC Secret Code Reference (second byte of AC Secret Code Referein the variable part of the file descriptor).

RFU The next three bytes return 00h

Checksum Checksum of bytes in the file descriptor.

© GEMPLUS 2000


ret

nce

For EFs:

For more details about these variables, see “Elementary Files” on page 11.

Fp File Pedigree

Fn File number

File Identifier The five lsb are the SFI


RecLgt Record length byte. This is in the variable part f the file descriptor.

Body Size Size H and Size L


AC Secret Code Reference (first – most significant – byte of AC SecCode Reference in the variable part of the file descriptor).


AC Secret Code Reference (second byte of AC Secret Code Referein the variable part of the file descriptor).


AC Secret Code Reference (third – least significant – byte of AC Secret Code Reference in the variable part of the file descriptor).

RFU The next three bytes return 00h

Checksum Checksum of bytes in the file descriptor.


© GEMPLUS 2000


Select File Key

Computes a temporary administration key using a specified key, and then a cryptogram using this temporary administration key. This command cannot be used to set up a temporary payment transaction key (this would have to be done by the Select Purse & Key command).

The temporary key is used for the secure messaging process on non-payment commands. The terminal can retrieve the cryptogram using the Get Response command, and then use this value to authenticate the card and compute its own temporary key.

Only one active temporary key is allowed at a given time, therefore by issuing this command, any earlier temporary keys will be lost, regardless of whether or not the command is successful. This also applies to keys that were set up using the Select Purse & Key command.

It may be necessary to perform external authentication before this command can be used. This is determined by the Options byte in the file descriptor of the current DF (see “File Descriptor” on page 6).

On receiving the command, the card executes the following procedure:

1. It makes sure that the specified key is valid, and is not a payment type key (this is defined in the specified Key Type field) (see “3DES Key Files” on page 21).

2. The card then generates its own four-byte random number, (CRnd), and computes the temporary administration key using the following formula:

Kats = 3DES_16 (RN, K)

Where:

RN is a concatenation of the four MSB of the Terminal Random number and the four MSB of CRnd.

K is the key specified by the command.

3. It computes authentication cryptogram CR using the following formula:

CR = 3DES (TRnd, Kats)

Where:

TRnd is the random number generated and sent by the terminalKats is the temporary key that was previously generated by the card.

4. It prepares the following response:

Where:

CR3 through CR0 hold the four LSB of the cryptogram CR, computed by the cardRN is as shown above. The terminal can retrieve this value using the Get Response command.

5. The command then activates a flag to indicate that a temporary administration key has been established.

TRnd7 TRnd6 TRnd5 TRnd4 CRnd7 CRnd6 CRnd5 CRnd4

RNCR3 CR2 CR1 CR0

© GEMPLUS 2000


Format

Where:

Kn specifies the key number in the EFKey that will be used to compute the temporary key. This value is sent in the following format:

The number of a 3DES key must be an even number.

Kf specifies the EFKey with the key that will be used to compute the temporary administration key. This value is sent in the following format:

EFKey is the EFKey file SFI.

TRnd is an eight-byte random that is generated and sent by the terminal.

Response

Where:


80h 28h Kn Kf 08h TRnd

Where:

L specifies the level of the EFKey file as follows:

0 Global

1 Local

Bit 7 6 5 4 3 2 1 0

Key Number 0

Bit 7 6 5 4 3 2 1 0

00 L EF Key

Note: To enable secure messaging, the EFKey file specified in this field must be the same as that specified in the access condition Key File field.

SW1 SW2


© GEMPLUS 2000


Set Card Status

This command defines the card status by setting the lock byte. For details on this byte, see “Lock Byte” on page 44. This lock byte is located in the OTP (one time programmable) memory to ensure irreversibility. The card status options are as follows and apply to all applications in the card:

• Personalization complete (or not)

• Data unit

Format

Where:

For details on how to code the lock byte, see “Lock Byte” on page 44.

Response

Where:

Note: It is very important that you set the personalization bit once personalization has been completed so that you can trace which processes have been completed by your card.


80h D8h FFh FFh Lc Lock byte

Lc specifies the length of the data, in bytes, to be updated. This value must be from 1 to 255 (1 to FFh).

Note: This value must be entered in hexadecimal notation.

Lock byte holds the new value of the lock byte to be updated in the OTP Memory.

SW1 SW2


© GEMPLUS 2000


code

n an

n its value

cret

de to

de

not , if

Set Secret Code

Unblocks and/or changes a secret code in the secret code Elementary File (EFsc) under the currently selected Dedicated File (DF) (which may be the Master File (MF)). There is no limit to the number of times that a secret code can be changed, as long as the Access Conditions (ACs) are satisfied.

The command acts implicitly on the EF Secret Code in the current DF, so there is no need to explicitly select the EFsc before issuing the command. If there is no EFsc in the current DF, then the command is rejected.

Unblocking Secret CodesThe command specifies the unblock secret code value and a replacement value for the blocked secret code. When the card receives the command, it checks the submitted unblock secret code value against the secret code value in the UCR byte of the secret code you wish to unblock (see “Secret Code Files” on page 33). This UCR byte also defines the level (global or local) of the EFsc.

If the comparison is successful, the card executes the following procedure:

• It sets the blocked Secret Code Ratification counter to 0.

• It sets the appropriate bit to 1 in the local authorization register as a result of theunblock secret code being successfully submitted.

• It replaces the blocked secret code value with the specified replacement secret value.

If the comparison is not successful, the card increments the Secret Code Ratificatiocounter in the unblock code, does not update the authorization register, and returnserror code.

Changing Secret CodesThe command specifies the current secret code value and a value to replace it withidata field. On receiving the command the card checks that the submitted secret codeis that of the specified secret code.

If the comparison is successful, the card executes the following procedure on the secode to be changed:

• Sets its Secret Code Ratification counter to 0.

• Sets the appropriate bit to 1 in the local authorization register as if the secret cobe changed had been correctly entered using the Verify command.

• Replaces the original secret code value with the specified replacement secret covalue.

If the comparison is not successful, the card returns an appropriate error code, doeschange the local authorization register, and increments the Secret Code Ratificationcounter. If the Secret Code Ratification counter reaches the Maximum PresentationNumber value, the card blocks the secret code. In this case the unblock secret codeany, has to be submitted.

Note: This command cannot be applied to the Transport Secret Code.

© GEMPLUS 2000


cret

Secure MessagingWhen unblocking a secret code, the unblock secret code value and blocked code replacement value sent in the command data field must be enciphered if the unblock secret code is flagged as enciphered (see “Secret Code Files” on page 33).

When replacing a secret code, the current secret code value and replacement secret code value in the command data field must be enciphered if the value of “Mode” in the secode is 1.

In either case, certain conditions must be met before executing this command (see “Secure Messaging” on page 59). The terminal enciphers the data field and sends it on eight bytes using the following process:

Enciphered Value = 3DES -1(Value1/Replacement Secret Code Value, Kats)

Value1 is the unblock secret code value if you are unblocking a secret code, or the current secret code value if you are changing a secret code.

Kats is the temporary key calculated by the card when the Select File Key or Select Purse & Key (using a log key) command was executed.

Format

Where:

CLA specifies the transmission mode (normal or secure messaging):

80h Transmit normally84h Transmit using secure messaging.

Mode specifies the command execution mode:

00h Change secret code01h Unblock secret code

SCN specifies the secret code number (from 0 through 7) to be changed or unblocked in the secret code file for the currently selected DF.

Data holds the following values:

Where:

SC Value1 is the four-byte unblock secret code value for unblocking a secret code (mode = 01h) or

the four-byte current secret code value for changing a secret code (mode = 00h)

Replacement SC Value is the four-byte replacement secret code value


CLA 24h Mode SCN 08h Data

Byte 7 6 5 4 3 2 1 0

SC Value 1 Replacement SC Value

© GEMPLUS 2000


Response

Where:

SW1 SW2

SW1 and SW2 hold the status byte values returned by the card. “Appendix B -Card Return Codes” lists the possible contents of SW1 and SW2.

© GEMPLUS 2000


Switch Speed

Selects the card speed. Once this command has been executed, the card implements the new speed until either the Switch Speed command is executed again or a new session is started.

Format

Where:

P1 This byte indicates the transmission bit rate adjustment factor as defined in ISO 7816-3 as the coding for the TA1 byte.

Assuming F is the clock conversion factor, D is the bit rate adjustment factor and fs is the terminal clock frequency, the bit duration (called ETU for Elementary Time Unit) is calculated as follows:

ETU = F/(D * fs)

The F/D ratio identifies the number of clock cycles in one ETU and is the absolute reference used by the card to set the communication speed.

Example:

F/D = 372 is the default value and corresponds to a baud rate of 9,600 baud when fs = 3.5795 MHz.

F and D are referenced by the integers Fi and Di respectively (see ISO 7816-3). Fi and Di are coded on four bits and are read from a table as defined in ISO 7816-3. The F/D ratio is coded on one byte and is the concatenation of Fi || Di.

CLA INS P1 P2 Lc

80h 14h P1 P2 00h

Note: Unlike the ISO specifications, F does not specify any maximum clock frequency and is only used to define the ETU.

© GEMPLUS 2000


The following table lists the values for F/D that are available for GPK:

The following table summarizes the GPK capabilities:

In these examples, 3.68 MHz corresponds to the clock frequency available from the GemPC410 reader.

D-Di

1 2 4 8 16 32 12 20

F/D 0001b 0010b 0011b 0100b 0101b 0110b 1000b 1001b

372 0001b 372

558 0010b

744 0011b

F-Fi 1116 0100b

1488 0101b

1860 0110b

512 1001b 64 32

768 1010b

1024 1011b

1536 1100b

2048 1101b

Table 28 - F/D Values

P1 value Comm.

speed Bauds

Reader Freq.

MHz

F / D

- ISO7816-3

11h 9,600 3.5795 372 / 1

94h 57,600 3.6864 512 / 8

95h 115,200 3.6864 512 / 16

Table 29 - GPK Baud and Reader Frequencies.

P2 specifies the protocol and card extra guard time. This has the following format:

Figure 42 - CEGT Format

Bit 7 6 5 4 3 2 1 0

CEGT0 0

© GEMPLUS 2000


Response

Where:

CEGT specifies the Card Extra Guard Time. This is the number of extra Elementary Time Units (ETU)s to be inserted between each character in transmissions from the card. This can be used when the card is configured for high transmission speeds to reduce the rate of data flow from the card to a rate that is compatible with the terminal. This value should be 0h in most cases.

SW1 SW2


© GEMPLUS 2000


Update Binary

Updates data in an Elementary File (EF). This command can only be executed when the Group 1 access conditions are fulfilled. If the key file indicated in the access condition is zero, normal processing is used; otherwise secure messaging is used (see “Access Conditions” on page 46).

Update Binary can be used either to select a file then update it, or to update the currently selected file. In the former case, the selected file becomes the currently selected file. If the card encounters any errors at this stage, it leaves the previously selected file as the currently selected file.

Secure MessagingThis command can use secure messaging, as long as certain conditions are met, see “Secure Messaging” on page 59.

If the terminal is updating any file other than EFsc or EFKey it sends the data to be written in plain text with the three LSB of the cryptographic checksum. The amount of data that can be sent to the card is limited to 61 bytes (buffer size of 64 bytes minus three bytes for the cryptographic checksum). For further details see“IO Buffer Size” on page 43.

If the terminal is updating an EFsc or an EFKey it encrypts the updated data before sending it.

The encrypted data field is a concatenation of two eight-byte fields, thus it is 16 bytes long. The terminal encrypts the data as follows:

Data field = Data field 1 || Data field 2

Where:

Data field 1 = 3DES -1(Data1 || Data2, Kats)


Kats is the temporary administration key computed by the card when it executed the Select File Key or Select Purse & Key (using a log key) command.

The contents of the Data1 to Data4 depend on the actual file being updated. The following table gives the contents of Data1 to Data4:

© GEMPLUS 2000


When the card receives the command, it decrypts the data and performs a redundancy check on it. If the redundancy does not match the data, access is refused and an appropriate error code is returned. If the redundancy check does match the data, the card executes the update.

After executing the update, the card generates a three-byte cryptographic certificate for the command. The terminal can retrieve this certificate by executing the Get Response command (see “ Get Response” on page 103).

The card generates the certificate as follows:

Cryptogram = 3DES [data1 || data2, Kats]

Certificate = [Cryptogram] 7-5

Where:

Kats is the temporary administration key computed by the card when it executed theSelect File Key command.

When Updating an EFsc When Updating an EFKey

Data1 The following values from the secret code descriptor:

The following values from the key descriptor:

Mode MPN SCR 0h UCR CKS Key type 00h Kv Cks

For further details see “Secret Code Files” on page 33.

For further details see “3DES Key Files” on page 21.

Data2 The four-byte secret code. The four MSB of the key

Data3 Data2 The four LSB of the key

Data4 The P1 and P2 parameters (see below), + a two-byte sum of the 14 previous data bytes.

The P1 and P2 parameters (see below), + a two-byte sum of the 14 previous data bytes.

Table 30 - Data Encryption for Update Binary

Note: The terminal can only update one key or one secret code at a time.

© GEMPLUS 2000


The contents of Data1 and Data2 depend on the file that was updated. The following table gives the contents of Data1 and Data2:

File TypeThis command can be executed on transparent EFs.

Format

Where:

EFsc EFKey






Data2 The P1 and P2 parameters (see below), + the two-byte sum that was sent with the incoming cryptogram (in Data4).

The P1 and P2 parameters (see below), + the two-byte sum that was sent with the incoming cryptogram (in Data4).

Table 31 - Certificate Computation for Update Binary


CLA D6h P1 P2 Lc Data




© GEMPLUS 2000


P1, P2 To update the currently selected EF, P1 and P2 specify the offset, in data units, from the beginning of the file to the first byte to be updated. The data unit is defined during personalization and is equal to either one or four bytes. This information can be found in the lock byte by using the Get Info command. Send P1 and P2 in the following format:

To select and update an EF other than the currently selected one, P1 specifies the file to be updated from using its SFI). P2 specifies the offset, in data units, from the beginning of the file to the first byte to be updated. Send P1 and P2 in the following format:

Note: If a key or a secret code is being updated using secure messaging, the offset must specify the position of the first byte of the code or key to be updated. This value will therefore be a multiple of two for a secret code and a multiple of three for a key.

Lc Specifies the length of the update data, in bytes. The following table shows the possible values for this field:

Data is as described previously.

� 2IIVHW��06%�

3� 3�

2IIVHW��/6%�

� 6),

3� 3�

2IIVHW; ;

Enter This Value Under These Circumstances

Length of update data

If you are updating without secure messaging.

16 If you are updating an EFsc or an EFKey using secure messaging.

Length of update data + 3

If you are updating any other file using secure messaging.

Table 32 - Lc and Field Values for Update Binary

© GEMPLUS 2000


Response

Where:

CRYCKS 7-5 SW1 SW2



© GEMPLUS 2000


n’

Update Record

This command is used to update data in a structured file.

File selection can be direct or implicit. When direct selection is used, it means that the file will already have been selected using the Select File command. For implicit selection, the file is selected in the current DF, using the SFI. If the selection is successful, the selected file becomes the current file and the record pointer is cleared.


File TypeThis command can only be executed on structured Elementary Files (EFs).

Format

Where:

Note: If the Update Record command is performed on any file that is not yet complete, it will not be possible to perform an Append Record command as the next command. See the example in “Cyclic Files” on page 17 for an explanation.


CLA DCh P1 P2 Lc Data

CLA specifies transmission mode (normal or secure messaging):



P1 is the number of the record to be updated. For cyclic files, P1 must be zero, which refers to the current record.

P2 specifies the SFI for the file from which the record is to be updated. In the case of direct selection, the file will have been previously selected using the Select File command and SFI is set to zero.

Lc specifies the length of the record to be updated. If secure messaging is being used, a value of 03h should be added. If Lc is greater than the available data length or is set to zero, GPK will return the code ‘6C n(where nn is the available data length).

Data data to be written to the updated record.

Record Number

P1 P2

SFI 1 0 0

© GEMPLUS 2000


Response

Where:

CRYCKS 7-5 SW1 SW2



© GEMPLUS 2000


Verify

Compares the value submitted to the secret code number (0 to 7) in the EFsc (secret code file) in the currently selected DF. If there is no secret code file in the currently selected DF, the card returns an error code.

On receiving the command the card increments the Secret Code Ratification counter then performs the comparison. The ratification mechanism is described in “Secret Code Files” on page 33.

If the comparison is successful, the card sets the appropriate bit to 1 in the local authorization register and sets the Secret Code Ratification counter to zero.

If the comparison is not successful the card returns an appropriate error code, and does not set the Secret Code Ratification counter to zero. If the Secret Code Ratification counter reaches the Maximum Presentation Number value, the card locks the secret code. In this case the unblock secret code has to be submitted.

Secure MessagingIf the secret code is flagged as enciphered (see “Secret Code Files” on page 33), the terminal has to encipher the secret code value before submitting it. In this case, the terminal establishes a temporary administration key before executing the Verify command. The key to be used for this can be of any type. The terminal enciphers the value to be submitted using the following process:

Enciphered Value = 3DES -1(Value, Kats)

Where:

Note: Blocking a secret code only blocks functions protected by that code, those protected by other codes are not affected.

Value is the value to be compared to the secret code.

Kats is the temporary administration key computed by the terminal and the card when it executed the Select File Key or Select Purse & Key (using a log key) command.

© GEMPLUS 2000


Format

Where:

Response

Where:


CLA 20h 00h SCN 08h SCvalue




SCN Specifies the secret code number (0 to 7) in the EFsc for the currently selected DF. The value FFh specifies the transport secret code.

SCvalue holds the value to compare to the secret code specified in SCN. If secure messaging is in use, this value is enciphered.

SW1 SW2


© GEMPLUS 2000


Write Binary

Writes data to an Elementary File (EF) by performing a logical OR operation using the current value of the write area and the value being written. This command can only be executed when the Group 2 access conditions are fulfilled. If the key file indicated in the access condition is zero, normal processing is used, otherwise secure messaging is used (see “Access Conditions” on page 46).

Write Binary can be used either to select a file and write to it or to write to the currently selected file. In the former case, the selected file becomes the currently selected file. If the card encounters any errors at this stage, it leaves the previously selected file as the currently selected file.

Secure MessagingThis command can use secure messaging, as long as certain conditions are met, see “Secure Messaging” on page 59.

If the terminal is writing to any file other than EFsc or EFKey it sends the data to be written in plain text with the three LSB of the cryptographic checksum. The amount of data that can be sent to the card is limited to 61 bytes (buffer size of 64 bytes minus three bytes for the cryptographic checksum). For further details see “IO Buffer Size” on page 43.

If the terminal is writing to an EFsc or an EFKey it encrypts the data to be sent before sending it.

The encrypted data field is a concatenation of two eight-byte fields, thus it is 16 bytes long. The terminal encrypts the data as follows:

Data field = Data field 1 || Data field 2

Where:



Kats is the temporary administration key computed by the card when it executed the Select File Key or Select Purse & Key (using a log key) command.

The contents of the Data1 to Data4 depend on the actual file being written to. The following table gives the contents of Data1 to Data4:

© GEMPLUS 2000


When the card receives the command, it decrypts the data and performs a redundancy check on it. If the redundancy does not match the data, access is refused and an appropriate error code is returned. If the redundancy check does match the data, the card executes the Write Binary command.

After executing the Write Binary command, the card generates a three-byte cryptographic certificate for the command. The terminal can retrieve this certificate by executing the Get Response command (see “ Get Response” on page 103 command).

The card generates the certificate as follows:

Cryptogram = 3DES [data1 || data2, Kats]

Certificate = [Cryptogram] 7-5

Where:

Kats is the temporary administration key computed by the card when it executed theSelect File Key command.

EFsc EFKey






Data2 The four-byte secret code. The four MSB of the key

Data3 Data2 The four LSB of the key

Data4 The P1 and P2 parameters (see below), + a two-byte sum of the 14 previous data bytes.

The P1 and P2 parameters (see below), + a two-byte sum of the 14 previous data bytes.

Table 33 - Data Encryption for Write Binary

Note: The terminal can only write one key or one secret code at a time.

© GEMPLUS 2000


The contents of Data1 and Data2 depend on the file that was written to. The following table gives the contents of Data1 and Data2:

File TypeThis command can be executed on transparent EFs.

Format

Where:

EFsc EFKey






Data2 The P1 and P2 parameters (see below), + the two-byte sum that was sent with the incoming cryptogram (in Data4).

The P1 and P2 parameters (see below), + the two-byte sum that was sent with the incoming cryptogram (in Data4).

Table 34 - Certificate Computation for Write Binary


CLA D0h P1 P2 Lc Data




© GEMPLUS 2000


P1, P2 To write to the currently selected EF, P1 and P2 specify the offset, in data units, from the beginning of the file to the first byte to be written. The data unit is defined during personalization and is equal to either one or four bytes. This information can be found in the lock byte by using the Get Info command. Send P1 and P2 in the following format:

To select and write to an EF other than the currently selected one, P1 specifies the file to write to from using its SFI. P2 specifies the offset, in data units, from the beginning of the file to the first byte to be written. Send P1 and P2 in the following format:

Note: If a key or a secret code is being written using secure messaging, the offset must specify the position of the first byte of the code or key to be updated. This value will therefore be a multiple of two for a secret code and a multiple of three for a key.

Lc Specifies the length of the data, in bytes, to be written. The following table shows the possible values for this field:

Data is as described previously

� 2IIVHW��06%�

3� 3�

2IIVHW��/6%�

� 6),

3� 3�

2IIVHW; ;

Enter This Value Under These Circumstances

Length of data to be written

If you are writing without secure messaging.

16 If you are writing to an EFsc or an EFKey using secure messaging.

Length of data to be written

If you are writing to any other file using secure messaging.

Table 35 - Lc and Field Values for Write Binary

© GEMPLUS 2000


Response

Where:

CRYCKS 7-5 SW1 SW2



© GEMPLUS 2000

© GEMPLUS 2000

12
Payment Commands
This chapter gives a comprehensive description of the commands that are used to perform payment transactions in GPK. The commands are listed in alphabetical order. The following table gives a brief summary of these commands:

Where:

Cmd. Full Name Description

CanDeb Cancel Debit Cancels the previous debit performed by a terminal and optionally replaces it by a new debit.

Credit Credit Credits a purse

Debit Debit Debits a purse

RdBal Read Balance Reads the specified purse balance value

SelP&K Select Purse & Key

Selects the specified purse and key, then generates a new temporary payment transaction key and an authentication cryptogram

SetOpts Set Options Sets the following Sign command options:

- use current purse balance in the certificate calculation

- clear the RAM parameters after executing the Sign command

Sign Sign Generates a certificate for the previous transaction

Table 36 - Payment Commands

Cmd. is an abbreviation of the command name.

Full Name specifies the command name.

Description offers a brief description of the command function.

138 Payment Commands

the lue ored

ep it

um

der

Cancel Debit

This command cancels the previous debit performed on the card. Optionally, it can be used to replace the previous debit by a new one.

This command can be disabled during the personalization step when creating the corresponding DF. It cannot be used if a Credit command has been executed since the last Debit transaction.

Before canceling a debit, the card checks that the following conditions are met:

• The parent DF options byte (OPT) allows the command to be executed (see “OPT” on page 10).

• A temporary payment transaction key has been established (see “ Select Purse & Key” on page 150).

• The Debit to be canceled was performed by the same terminal which is executingcurrent Cancel Debit command. For this purpose, the card checks that the TTC vatransmitted by the terminal to cancel the debit is consistent with the TTC value stin the card during the previous debit session.

• The Debit to be canceled is consistent with the last Debit performed with the card.

When a replacement debit is requested, the card actually cancels the previous Debit and then debits the specified replacement value from the purse. Before executing this stchecks that the following conditions are met:

• The Debit access condition is fulfilled if the debit value is greater than the maximfree debit value (see“Purse Files” on page 19),

• The debit value is less than or equal to the current balance.

The Debit access conditions are summarized in the following table:

The Debit access condition, Cd, and the maximum free debit value are described un“Purse Files” on page 19.

The card completes the debit cancellation by issuing a certificate. If a replacement debit has been requested, this certificate will be similar to a card debit certificate (CDC) using the replacement debit value. The terminal can retrieve the two MSB of this certificate using the Get Response command.

Debit Value <= Max. Free Debit

Debit Value >Max. Free Debit

Cd = 0 Yes Yes

0< Cd <8 Yes Yes if Cd Satisfied

Cd > 7 No No

Table 37 - Cancel Debit Access Condition

© GEMPLUS 2000

Payment Commands 139

Format

ResponseThe card computes a Cancel Debit Certificate (CDC). The two MSB can be retrieved by the terminal using Get Response.

The card generates the CDC as follows:

When a replacement debit value has been requested, the card computes a replacement Card Debit Certificate (CDC) instead. The two MSB can be retrieved by the terminal using Get Response.

The card generates the CDC as follows:


80h 46h 00h 00h 0Ch Data

Where:

Data specifies the last debit value and the Cancel Debit Cryptogram (SDC).This value has the following format:

00h Dv2 Dv1 Dv0 SDC7 SDC6 ... SDC1 SDC0

Where:

Dv2 to Dv0 hold the last debit value.

SDC7 to SDC0

hold the Cancel Debit Cryptogram (SDC)

The terminal generates the SDC as follows for debit cancellation:

SDC = 3DES-1 ( 00h 00h 00h 00h TTC3 TTC2 TTC1 TTC0 ,Kpts)

If a replacement debit is requested, the terminal generates the SDC as follows:

SDC = 3DES-1 ( 00h Rv2 Rv1 Rv0 TTC3 TTC2 TTC1 TTC0 ,Kpts)

Rv2 to Rv0 is the replacement debit value (this is set to 00 for debit cancellation).

TTC3 to TTC0

is the Terminal Transaction Counter value. GPK compares the two MSB of the TTC (that contain the terminal serial number) with the TTC value stored in the purse during the previous Debit, to verify that the terminal is the one used to perform the original Debit.

Kpts is the temporary payment transaction key.

CDC = 3DES ( 00h Pf 00h 00h 00h TTC2 TTC1 TTC0 ,Kpts)

CDC = 3DES ( 00h Pf Rv2 Rv1 Rv0 TTC2 TTC1 TTC0 ,Kpts)

© GEMPLUS 2000


te.

Where:

The terminal can retrieve the Cancel Debit command response using the Get Response command (see “ Get Response” on page 103). The card generates the response in thefollowing format:

Where:

The processing of the Cancel Debit command is summarized in the following diagram:

Figure 43 - Cancel Debit Command Processing

Pf is the SFI of the purse on which the Cancel Debit was executed. This identifier has the following format:

Rv2 to Rv0 is set to 00 for debit cancellation or the replacement debit value.

TTC3 to TTC0

is the Terminal Transaction Counter value.


CDC7 CDC6 SW1 SW2

CDC7, CDC6

are the two MSB of the Cancel Debit Certificate or Card Debit Certifica

SW1, SW2 are the status bytes. See “Appendix B - Card Return Codes” for a list of the status byte values and their descriptions

Bit 7 6 5 4 3 2 1 0

00 Purse File0

Terminal GPK Card

Compute SDC:

SDC = 3DES (00, TTC, Kpts)

Cancel Debit (Dv, SDC)

GetResp

(CDC)

Decrypts SDC.

Checks the following:

– Dv = Bal = Pbal

– TTC sent is compatible with previous

Stores TTC (2 MSB) in purse.

Computes Cancel Debit Certificate

CDC = 3DES (00, Pf, 00, 00, 00, TTC, Kpts)

© GEMPLUS 2000


When a Debit replacement is requested, the command behavior is as follows:

Figure 44 - Cancel Debit Command Processing (Replacement Debit Requested)

The abbreviations used in the above diagram are as follows:

Bal Active, or current balance

CDC Cancel Debit Certificate

or Card Debit Certificate if a replacement was requested.

Dv Previous debit value

Kpts Temporary payment transaction key

PBal Balance before previous debit

Pf The purse file

Rv Replacement debit value

SDC Cancel Debit Cryptogram

TTC Terminal Transaction Counter

Terminal GPK Card

Compute SDC:

SDC = 3DES (Rv, TTC, Kpts)

Cancel Debit (Dv, SDC)

GetResp

(CDC)

Decrypts SDC.

Checks the following:

– Dv = Bal = Pbal

– TTC sent is compatible with previous

- Rv <= Bal

Computes new balance (Nbal)

Stores TTC (2 MSB) in purse.

Computes Card Debit Certificate

CDC = 3DES (0, Pf, 00, TTC, Kpts)

Note: If an error is encountered while GPK is executing a Cancel Debit command, the terminal cancels the debit. If a replacement debit had been requested, the terminal cancels the debit but the replacement debit is not made.

Caution: The Cancel Debit command cannot cancel a debit that has already been replaced.

© GEMPLUS 2000


e

s

ent e al.

the

e

Credit

Credits the specified value to a purse. This command can only be executed if the following conditions are met:

• The Select Purse & Key command has been previously executed to select a pursand establish a temporary payment transaction key.

• A Debit has not been executed since the last Select Purse & Key command.

• If the purse to be credited is an enhanced purse, the credit secret code, if any, isuccessfully submitted.

• The credit amount will not cause the purse to exceed the maximum allowable balance.

The temporary key used by the card to validate the Credit Cryptogram can be differfrom the temporary key used for card/terminal authentication. This enables an on-linhost to perform the Credit operation using a credit key that is not known by the termin

Format

Where:


80h 36h Kn 00h 0Ch Data

Kn specifies the number of the credit key in the credit key file specified by purse (see “Purse Files” on page 19) to be used to compute the Credit Cryptogram. This may be a payment key, a signature key, or a log key (see “3DES Key Files” on page 21). Kn is sent in the following format:

Kn is coded on bits 7-1 of P1. Bit 0 of P1 is always 0 to maintain compatibility with PCOS.

Data Holds the following 12 bytes of data:

Cv2–Cv0 Correspond to the credit value.

CC"7–CC"0 Correspond to the Credit Cryptogram. Either the host, thterminal, or both generate this using the following procedure:

Bit 7 6 5 4 3 2 1 0

Key Number 0

00h Cv2 Cv1 Cv0 CC"7 CC"6 CC"5 CC"4CC"3 CC"2 CC"1 CC"0

© GEMPLUS 2000


The Credit command processing is summarized in the following diagram:

Figure 45 - Credit Command Processing

1. Compute a temporary key (Kt) based on the credit key, Kc, (whose number is indicated in the P1 parameter) and the Card Transaction Counter (CTC, which has been retrieved by the terminal during the previous Select Purse & Key command) as follows:Kt = 3DES_16 (CTC, Kc)

2. Generate a Credit Cryptogram (CC) using the following data:

Pf specifies the Short File Identifier of the purse file to be credited, in the following format:

Cv2 to Cv0 correspond to the credit value.

3. Encrypt the Credit Cryptogram (CC) as follows:

CC’ = 3DES-1(CC, Kt)

4. Encrypt CC’ with the temporary payment transaction key (Kpts) as follows:

CC" = 3DES-1(CC’, Kpts)

CC = 00h Pf Cv2 Cv1 Cv0 00h 00h 00h

Bit 7 6 5 4 3 2 1 0

00 Purse File0

Host/Terminal GPK Card

Compute temporary session key.

Kt = 3DES_16 (CTC, Kc)

Generate Credit Cryptogram.

CC = (Pf, Cv, 0)

Encrypt CC

CC’ = 3DES-1 (CC’, Kt)

CC’, Cv

Encrypt CC’

CC" = 3DES-1 (CC’, Kpts)

Credit

(Kc Ref, Cv, CC") Decrypts CC".

CC’ = 3DES (CC", Kpts)

Computes temporary session key:

Kt = 3DES_16 (CTC, Kc)

Decrypt CC’.

CC = 3DES (CC’, Kt)

Verify CC consistency.

Update balance.

© GEMPLUS 2000


The following abbreviations are used in the previous figure:

Response

Where:

CC Credit Cryptogram

CTC Card Transaction Counter


Kc Credit key

Kt Temporary key

Note: Consecutive Credit operations are not allowed unless a new temporary credit key is established before each operation.

SW1 SW2

SW1 and SW2 are the status bytes. See “Appendix B - Card Return Codes” for a list of the status byte values and their descriptions

© GEMPLUS 2000


a

er

Debit

Debits a purse. To execute this command, the following conditions must be fulfilled:

• The Select Purse & Key command must have been previously executed to selectpurse and establish a payment transaction temporary key.

• The Debit access condition must be fulfilled if the debit value is greater than the maximum free debit value see “Purse Files” on page 19.

• The Debit value is less than or equal to the current balance.

The Debit access conditions are summarized in the following table:

The Debit access condition Cd and the maximum free debit value are described und“Purse Files” on page 19.

When the Debit operation is performed, the card calculates the new balance of the purse and computes a card debit certificate in response to the command.

Format

Debit Value <= Max.

Free Debit

Debit Value >Max. Free Debit

Cd = 0 Yes Yes

0< Cd <8 Yes Yes if Cd Satisfied

Cd > 7 No No

Table 38 - Debit Access Condition

Note: It is the Debit access condition in the purse file, Cd, that determines the debit access and not the access conditions in the file descriptor of the purse file.


80h 34h 00h 00h 08h Data

Where:

Data contains the following eight bytes of data:

00h Dv2 Dv1 Dv0 TTC3 TTC2 TTC1 TTC0

Where:

Dv2 to Dv0 hold the debit value.

TTC3 to TTC0 hold the TTC value in bytes. GPK stores the two MSB of the TTC in the debited purse. If a Cancel Debit command is issued, GPK uses these two bytes to verify that the Cancel Debit command has been issued by the same terminal as that which performed the debit to be canceled.

© GEMPLUS 2000


the

ResponseAfter performing the debit operation, the card computes a card debit certificate using the following formula:

Where:

The terminal can retrieve the Debit command response using the Get Response command (see “ Get Response” on page 103). The card generates the response in thefollowing format:

Where:

The processing of the Debit command is summarized in the following diagram:

Figure 46 - Debit Command Processing

CDC = 3DES ( 00h Pf Dv2 Dv1 Dv0 TTC2 TTC1 TTC0 ,Kpts)

Pf specifies the Short File Identifier (SFI) of the purse file to be debited in following format

Dv2 to Dv0 is the debit value.

TTC2 to TTC0



CDC7 CDC6 SW1 SW2

CDC7, CDC6

are the two MSB of the Card Debit Certificate.


Bit 7 6 5 4 3 2 1 0

00 Purse File0

Terminal GPK Card

Debit

(Dv, TTC)

GetResp

(CDC)

Card verifies that:

Balance >= Dv

If conditions satisfied:

Computes new balance

Computes CDC = 3DES (0, Pf, Dv, TTC, Kpts)

© GEMPLUS 2000


The following abbreviations are used in the previous figure:

CDC Card Debit Certificate

Dv Debit value


Pf Purse file


© GEMPLUS 2000


Read Balance

Reads the specified purse balance value. This command can be executed at any time as long as the Read Balance access condition has been fulfilled for the purse whose balance is to be read (see “Purse Files” on page 19).

Read Balance returns the balance value as well as the Card Balance Certificate (CBC).

Format

Where:

ResponseThe card generates the following response when it executes Read Balance:

Where:

This response can be retrieved using the Get Response command.

Note: If this command fails, the current purse pointer, purse references, and RAM indicators will be lost. The temporary payment transaction key will also be lost and the purse must be re-selected using the Select Purse & Key command.

If the temporary payment transaction key has not been established, (that is, using the Select Purse & Key command), the Read Balance certificate has no effect.

Purse access for Read Balance is based on the Cb access condition, regardless of the purse file access condition Cr.


80h 32h 00h Pf 04h Data

Pf specifies the Short File Identifier (SFI) of the purse file whose balance is to be read, in the following format:

Data contains the four-byte TTC value. This can be used to keep track of the commands sent by each terminal. If this feature is not required, the value 0 can be entered here.

Bit 7 6 5 4 3 2 1 0

00 Purse File0

00h Bv2 Bv1 Bv0 CBC5 CBC4 SW1 SW2

Bv2 to Bv0 is the current balance value read from the specified purse.

CBC5, CBC4

are bytes 5 and 4 of the Card Balance Certificate (see later).

SW1, SW2 are the status bytes. See “Appendix B - Card Return Codes” for a list of the status byte values and their descriptions.

© GEMPLUS 2000


The card generates the Card Balance Certificate using the following formula:

Where:

The Read Balance command processing is summarized in the following diagram:

Figure 47 - Read Balance Command Processing

Where: Bv, CBC, Kpts, Pf and TTC are as previously defined.

CDC = 3DES ( 00h Pf Bv2 Bv1 Bv0 TTC2 TTC1 TTC0 ,Kpts)

Pf is the SFI of the purse file whose balance is to be read,

Bv2 to Bv0 is the balance value.

TTC2 to TTC0



Terminal GPK Card

RdBal

(0, Pf, TTC)

GetResp

(Bc, CBC)

Card checks that Cb access condition has been satisfied.

Reads balance.

Computes CBC = 3DES (0, Pf, Bv, TTC, Kpts)

© GEMPLUS 2000


to be

(see

Select Purse & Key

Performs the following functions:

• Selects the specified purse and key

• Increments the Card Transaction Counter (CTC)

• Generates a new payment transaction temporary key

• Computes an authentication cryptogram

It is typically used to establish a payment transaction session, enabling transactionsperformed.

Depending on the setting of the Options byte in the file descriptor of the current DF “OPT” on page 10), it may be necessary to perform an External Authenticate command before the Select Purse & Key command.

When this command is executed, it overwrites the previously generated temporary key, even if this key was a temporary administration key (set up using the Select File Key command).

The card generates a new temporary payment transaction key using the following formula:

Kpts = 3DES_16 (00, 00, 00, 00, 00, CTC2, CTC1, CTC0, K)

Where CTC is the Card Transaction Counter value and K is the key specified by the command P1 and P2 bytes (see later). This key can be either a payment key or a log key.

Format

Where:

Note: When the terminal establishes a payment transaction session, it is recommended that the TTC is incremented each time a payment command is performed (“Terminal Transaction Counters” on page 61).


80h 30h Kn Kf 0Ah Data

Kn specifies the number of the key in the EFKey Kf to be used to compute the temporary key. This is sent in the following format:

The number of a 3DES key must be a multiple of 2.

Bit 7 6 5 4 3 2 1 0

Key Number 0

© GEMPLUS 2000


Where:

ResponseThe card generates the following response when it executes Select Purse & Key:

Where:

This response can be retrieved using the Get Response command.

The card computes the card cryptogram based on the random number (TRnd) (sent with the command) and the selected key. The cryptogram (CR) is then generated as follows:

CR = 3DES(TRnd, Kpts)

Where:

TRnd is the random number sent with the command

Kpts is the temporary payment transaction key

Kf specifies the SFI (on five bits) of the EFKey holding the key to be used to compute the temporary key. This 3DES key file is always addressed at the local level (that is, within the current DF).

Data holds the following 10 data bytes:

00h Pf TRnd7 TRnd6 TRnd5 TRnd4 TRnd3 TRnd2 TRnd1 TRnd0

Pf specifies the SFI of the purse file to be selected, in the following format:

TRnd7-0 hold an eight-byte random value that is generated by the terminal.

Bit 7 6 5 4 3 2 1 0

00 0 EF Key

Bit 7 6 5 4 3 2 1 0

00 Purse File0

CR3 CR2 CR1 CR0 00h CTC2 CTC1 CTC0 SW1 SW2

CR3 to CR0 are the four LSB of the card cryptogram (see later).

CTC2 to CTC0 are the Card Transaction Counter value.

SW1, SW2 are the status bytes. See “Appendix B - Card Return Codes” for a list of the status byte values and their descriptions.

Note: If the Card Transaction Counter reaches its maximum value, a specific error code is returned and the command becomes locked.

© GEMPLUS 2000


The following figure summarizes the Select Purse & Key command processing:

Figure 48 - Select Purse & Key Command Processing

The abbreviations used in the above figure are as follows:

CR is the Cryptogram

CTC is the Card Transaction Counter

K is the Key selected for temporary payment transaction key (Kpts) generation

Kpts is the temporary payment transaction key

Kn is the number of the key in the EFKey

Kf is the EFKey that is, file holding key K

Pf is the Purse file

TRnd is the random number generated by the terminal, used in cryptogram generation.

Terminal GPK Card

SelP&k

(Kn, Kf, 0, Pf, TRnd)

GetResp

(CR, CTC)

The terminal computes a cryptogram and checks it with the card cryptogram.

Increments CTC.

Calculates Kpts = 3DES_16 (CTC, K).

Checks and selects the purse.

Calculates CR = 3DES(TRnd, Kpts)

CDC = 3DES (0, Pf, Rv, TTC, Kpts)

© GEMPLUS 2000


es this

to

Set Options

Sets the Sign command options for the currently selected DF.

The sign options are as follows:

• Use current purse balance in the certificate calculation,

• Clear the following RAM parameters after executing the Sign command:

− last amount register

− purse pointer

− purse file reference

− authorization register

− the indicators (key indicator, debit indicator, transaction OK, data valid)

Once these options have been set, they remain unchanged until the terminal re-issucommand or starts a new session.

Format

Where:

Note: This command is only used for Electronic Purse applications.

CLA INS P1 P2 Lc

80h 3Ah 00h Op Empty

Op is the Options byte, defining the options. Send this byte in the following format:

Bits 7 to 2 are not used

Where:

RP To clear the RAM parameters after the Sign command is executed, enter the value 0 in bit 1. Otherwise, enter the value 1.

CB To prevent the current purse balance from being used in the certificate calculation, enter the value 0 in bit 0.

To include the current purse balance in the certificate calculation, enter the value 1 in bit 0.

Bit 7 6 5 4 3 2 1 0

RP CB

Note: Modifying the CB bit is only effective if bit 2 in the parent DF OPT byte is set 1, allowing the inclusion of the current purse balance in certificate calculation(see “File Descriptor” on page 6).

© GEMPLUS 2000


The selected options remain valid until changed by another Set Options command or another session is started.

Response

Where:

SW1 SW2

SW1 and SW2 are the status bytes. See “Appendix B - Card Return Codes” for a list of the status byte values and their descriptions.

© GEMPLUS 2000


e

rate

C is

r a

Sign

Generates a Card Signature Certificate (CSC) for the previous transaction, provided that a transaction has been successfully completed in the current purse transaction session. This command may be used at a later stage to verify the validity of transaction logs in the terminals. The CSC is based on the purse, transaction value, and optionally the purse balance (see “ Set Options” on page 153) after the transaction.

The card generates the CSC as follows:

CSC = 3DES (00h, Pf, Tv2, Tv1, Tv0, Bal2, Bal1, Bal0, Ks)

Where:

The card can also clear all the RAM parameters when it executes this command (se“ Set Options” on page 153).

Format

Note: A key other than the temporary payment transaction key can be used to genethe certificate so that the key is not known by the terminal.

Pf specifies the Short File Identifier (SFI) of the purse file for which the CScomputed, in the following format:

Tv2 to Tv0 is the previous transaction value.

Bal2 to Bal0 is the balance value after the previous transaction. This is optionally included; for further details see “ Set Options” on page 153.

Ks is the temporary signature key. The card computes this as follows:

Ks = 3DES_16(CTC, K)

Where:

CTC is the Card Transaction Counter value

K is the selected key. K may be a signature key, a payment key olog key.

Bit 7 6 5 4 3 2 1 0

00 Purse File0

CLA INS P1 P2 Le

80h 38h Kn Kf 04h

© GEMPLUS 2000


Where:

ResponseThe card returns the following response:

Where:

The Sign command processing is summarized in the following diagram.

Figure 49 - Sign Command Processing

Kn specifies the number of the key in the EFKey Kf to be used to compute the temporary key. This is sent in the following format:

Kn is coded on bits 7-1 of P1. Bit 0 of P1 is always 0 to maintain compatibility with PCOS. The number of a 3DES key must be a multiple of 2.

Kf specifies the SFI (on five bits) of the EFKey holding the key to be used to compute the temporary key. This 3DES key file is always addressed at the local level (that is, within the current DF).

Bit 7 6 5 4 3 2 1 0

Key Number 0

Bit 7 6 5 4 3 2 1 0

XX X EF Key

CSC3 CSC2 CSC1 CSC0 SW1 SW2

CSC3 to CSC0 are the four LSB of the CSC


Terminal GPK Card

Sign

(Kn, Kf)

(CSC3-0)

Ks = 3DES_16 (CTC, K).

Computes a card sign certificate.

Either:

CSC = 3DES (0, Pf, Tv, Ks)

or

CSC = 3DES (0, Pf, Tv, Bal, Ks)

© GEMPLUS 2000


The abbreviations used in the previous diagram are as follows:


K Key selected for the temporary key (Ks) generation

Kn Number of key K in file Kf

Kf File holding key K

Ks Temporary key

Pf Purse file

Tv The transaction value

Bal The balance value after the transaction

© GEMPLUS 2000

© GEMPLUS 2000

13
Public Key Cryptography Commands
This chapter gives a comprehensive description of the commands that are used to perform public key cryptographic operations in GPK, that is, signature, verification, encryption, unwrapping or key generation. The commands are listed in alphabetical order. The following table gives a brief summary of these commands:

Name Description

CreatePrivateKeyFile Creates the private portion of a public key file.

EraseCard Erases the application memory of the GPK card.

Generate RSA Key Generation of a public key and a private key CRT.

InitHashedData Loads previously hashed cryptographic data.

Load Private Key Loads a private key in a PK file.

PK_DIR Finds all public key files

PK_Int Auth Starts internal authentication based on PK algorithms.

PK_OpenEnvelope Unwraps a symmetric key or performs the RSA decryption of data (this data could be a symmetric key).

PK_Send Loads a public key into a public key file in preparation for a public key process.

PK_Sign Creates a digital signature.

PK_Verify Verifies a digital signature.

PutCryptoData Loads and hashes cryptographic data.

SelectCryptoContext Selects context (a file containing information about key used in PK algorithms).

Table 39 - Public Key Cryptography Commands

160 Public Key Cryptography Commands

Public Key Cryptography Command ProcessingGPK processes public key cryptographic commands in three steps:

Figure 50 - How to use Cryptographic Commands

ICCIFD

Context info

Process a cryptographic command

PK_Sign/PK_Int Auth/PKVerify

(in "Verify" or "Verify Certificate" mode)Cryptographic Result

Cryptographic Data


the operation mode chosen previouslyPuts the data to be treatedblock by block

Put Crypto Data, Init Hashed Data

Computes the cryptographic result

or PK_Send

No.1

Checks access conditions to the PK FileSets the hash function and the algo chosenSets the chosen operation (Sign or Verify)

Prepares the data according to

No.2

Sets flags eventually

No.3

Note: For unwrapping and key generation, the command sequence is different to that shown in the previous figure. Details of these sequences are given in the command descriptions for PK_OpenEnvelope (unwrapping) and Generate RSA Key (key generation).

© GEMPLUS 2000

Public Key Cryptography Commands 161

Create Private Key File

This command creates the hidden part of a key file (RSA/DSA) in the card. See “Note on DSA” on page 4.

If the private portion of the PK file already exists, an error code is returned.

To process this command the public portion of the PK file must have been created with a Tag0 initialization to define the type, the algorithm and the mode of the PK elements.

The Tag0 (system record) will be copied from the public portion of the PK file.

Format

Where:

Response

Where:

CLA INS P1 P2 Lc

80h 12h SFI W 00h

SFI is the Short File Identifier of the file.

W is the length (in words - four bytes) of the private portion of the PK file.

Caution: When specifying P2, do not forget to include the system record size.

SW1 SW2


© GEMPLUS 2000


ative

. he

t

tect

Erase Card

This command erases the card’s entire file structure from the beginning of the applicmemory.

This command becomes unavailable once BISSUER is set in the lock byte.

Format

Where:

Response

Where:

CLA INS P1 P2 Lc

DBh DEh 00h Offset 00h

Offset indicates (in words) the position in the EEPROM where erasing is to beginThe erasable area starts after EFSystem, thus an offset of 00h, erases all tEEPROM after EFSystem.

Caution: Remember to specify the offset in words, otherwise the command will noerase all of the memory that was intended.

Note: In GPK16000, the start of the applicative memory is defined during the personalization phase. This allows Gemplus to add filters to the card and prothem from being erased by the Erase Card command (by specifying the applicative memory to begin after the filter).

For earlier versions of GPK, this value is pre-defined.

SW1 SW2


© GEMPLUS 2000


Generate RSA Key

This command manages the generation of a public key and a private key CRT in a created EF key file. The public element is returned by the card and can be saved either in the card or a terminal. If the public element is saved in the card, it is saved in the public portion of the key file. The key must be 512 or 1,024-bits long. The EF key must have been created under a DF and this DF must be selected before the command can be used. The public element is returned with LSB first.

In GPK16000, an alternative method of generating RSA keys is available. This method is compliant with the X9.31 standard. For further information, please refer to standard, ANSI X9.31—Digital Signature Using Reversible Public Key Cryptography for the Financial Services Industry.

Format

Where:

Note: For GPK16000, the user can use the public exponent, v, of his or her choice. The exponent must be prime and must not exceed 67 bytes (536 bits). The exponent must already exist in the public portion of the specified file.

For older versions of GPK cards, the value of v is fixed at 10001h. This is done automatically by the Operating System (OS).

CLA INS P1 P2 Lc

80h D2h P1 P2 00h

P1 is coded as follows

Bit 7 6 5 4 3 2 1 0

EF KeyPK KG

Where:

PK 1 specifies that the public key portion is to be saved in the card

0 specifies that the public key portion is to be saved in the terminal

KG 00b specifies normal key generation

11b specifies X9.31 key generation

EFKey specifies the Short File Identifier (SFI) of the key file.

P2 specifies the length of the key

00h 512-bit key is used

11h 1,024-bit key is used

© GEMPLUS 2000


Response

Where:

Use the Get Response command to get the result of the generation as follows:

Where:

The response received is illustrated in the following table:

Conditions of Use and SecurityBefore the command is processed, the following steps are performed:

1. The public key file is created using the Create File command.

2. Tag0, the first record after the header is initialized using the Append Record command.

3. The private portion of the file is created using the Create Private Key File command. At this point, the appropriate space has been reserved for the private key elements.

SW1 SW2


CLA INS P1 P2 Le

00h C0h 00h 00h Le

Le is the length of the generated key, preceded by the status return bytes as follows:

42h 512-bit key generated

82h 1,024-bit key generated

Generation Status Data

OK 90h 00h Public key part (40h or 80h)

Memory failure 65h 81h

Incorrect length 6Ch Licc Licc is the length of data available. Get Response can be used again to retrieve the data.

© GEMPLUS 2000


Command Processing

Figure 51 - Generate RSA Key Command Processing

GenerateRSAKey (EF,Key length)

Verification phases (recommended):

Select contextPut Crypto Data

PKSign (to validate the generated keys)

Verification of S.

GetResponse loop

The private key and public keyportion must already be created.Tag0 must already be initialized.

Pre-Requisite:

Verifications:

Response: 90 00h

Signature S is returned

Key Generation

modulus: n, v

- Key size- File created- Access Conditions

IFD ICC

© GEMPLUS 2000


InitHashedData

This command enables hashed data, precomputed by the IFD, to be loaded in the card, in order to perform a PK_Int Auth or a PK_Sign command using the RSA algorithm only.

Before this command can be performed, a SelectCryptoContext must have been executed to determine the mode (hash algo, PK algo, and Short File Identifier (SFI)). If it has not, the InitHashedData command returns a “Wrong Context” error.

After this command is performed, the HASH flag is set to 1.

Format

Where:

Response

Where:

Note: This command is mandatory before a PK_Sign with the SSL mechanism. (special hashed data concatenation + special padding before signing).


RFU EAh RFU RFU Lc Data

Lc is the length of the hashed data

10h MD5 mode 11h, 31h in SelectCryptoContext)

14h SHA mode 12h, 32h in SelectCryptoContext)

24h SSL mode 18h, 38h in SelectCryptoContext) (MD5-Hash (16B)||SHA-Hash(20B))

Data is the data that has been previously hashed by the IFD.

SW1 SW2


© GEMPLUS 2000


Load Private Key

This command loads, and ensures the integrity and confidentiality of the private elements of a public key file in the card. These elements are:

For DSA (see “Note on DSA” on page 4).

X, the private value (20 bytes)

For RSA:

S, the private exponent, (size = N)

or the five CRT elements, (size = 5N/2)

The five CRT elements of size N/2, are concatenated in the following order:

Prime 1||Prime 2||Coefficient||Exponent 1||Exponent 2

Confidentiality is ensured by using 3DES encryption (ECB) with an administrative session key, Ksess, established by a SelFk command.

Maximum security is ensured by using the system key, Kt, to generate the session key to load the private elements in the card.

Integrity is ensured through a checksum given with the data block. This checksum is the complement of an XOR of the data (tag+private element), written next to the data.

Before this command can be executed, an administrative session key must have been computed using the Select File Key command. In addition, the following sequence of events must already have taken place.

1. The public key file must have been created using Create File.

2. Tag0, the first record after the header, must have been initialized using Append Record.

3. The private portion of the file must have been created using Create Private Key File. At this point, all the space for the private key elements has been reserved.

4. Before the private element can be stored in the PK file, the data must have been prepared as follows:

− A checksum computation: CKS

− Padding for DES

− Encryption ECB (tag//PrK element//CKS(padding for DES)) [Ksess]

After the card has decrypted the data and made various checks on it, the PrK element is stored in the card.

If the tag already exists in the file, the PrK element is ’Updated’; otherwise the PrK element is ’Appended’ even if the tag is incorrect (for example, unknown value or tag not compliant with the file type -DSA or RSA). If the file is full (so the element cannot be appended), an error code is returned.

Caution: For 512 and 768-bit keys, the IFD prepares the data to be loaded in one go.

For 1,024-bit keys, the CRT elements are stored individually, therefore it is necessary to perform the Load Private Key command five times.

© GEMPLUS 2000


Format

Where:

Response

Where:


80h 18h SFI P2 Lc Data

SFI is the Short File ID of the PK file (b4tob0 of P1).

P2 is the length of the PrK element only.

Lc is the length of the PrK element plus its tag and its checksum. Lc must be a multiple of eight bytes.

Data is the data to be loaded, divided into eight-byte blocks comprising the private element, its tag and the checksum.

TAG||Private Element||CKS||Padding (the whole data is encrypted).

Note: The command works as an “Update” or a “Write” according to the tag of the data to be loaded. The Update AC must be satisfied in order to use this command.

The checksum is:

CKS = com(xor (tag||private element)

SW1 SW2


Note: Tag0 has already been initialized through the Create Private Key File command.

The private element is sent in reverse order:

for example, signature exponent for RSA.

s to initialize s = 010203040506070809...64h

s to be sent s = 646362616059585756...01h

© GEMPLUS 2000


PK_Dir

This command searches the current DF for Public Key (PK) files and returns the Short File Identifier (SFI) (one byte) and Body Size (two bytes) for each PK file that it finds.

Format

Where:

Response

Where:

CLA INS P1 P2 Le

80h A0h RFU RFU Le

Le = 3*n (where n is the number of PK files found).

Files SW1 SW2

Files is the SFI and body size of the found PK files.


© GEMPLUS 2000


K

he

ontext

PK_Int Auth

This command signs hashed data in the card using the PrK_Ca (RSA: exp s or CRT/ DSA: exp xsign) for authentication purposes. See “Note on DSA” on page 4.

Before this command can be used, the following conditions must be met:

• The SelectCryptoContext command must have been issued to set the context (Pfile selection, algorithm and hash function selection, operation mode selection).

• The PutCryptoData or InitHashedData command must have been used to send tterminal random number (TRnd) or the hashed data to the card.

If hashed data is available (the signature will process a hash of the TRnd), and the cis selected correctly, the signature process works.

Format

Where:

Response

Where:

CLA INS P1 P2 Le

80h 88h RFU Padding Le

Padding is the type of padding to be used.

00h to sign with PKCS#1 padding.

01h to sign with ANSI X9.31 padding

02h to sign with ISO 9796-2 padding

Note: ISO 9796-2 padding can only be used if the SHA algorithm was specified with the SelectCryptoContext command.

Le is the length of the PK modulus for RSA

is the length of R and S concatenated for DSA

Note: A DSA signature is composed of two parts, R and S. R isused in the computation and verification of S.

Signature SW1 SW2

Signature is the signature of the TRnd.


© GEMPLUS 2000


Command Processing

Figure 52 - PK_Int Auth Command Processing

IFD ICC

PuKIcc, PrKIcc, CertIccPuK_Ca

PuK_Ca

Select Context(SFI_card,Mode )

Template to describe the signed data

Put Crypto Data Data Computes HH=hash(Data)

Data may be internal card data or external data

Normal Internal Authentication Proces

PuKIFD(mod, exp)

Init Hashed Data

Or

Data already hashed by the terminal, loadedin the card before signing with RSA algo.

H=DataCorresponds to the hash function sele

Checks the file typeaccording to the mode

PK_Int Auth

S' If hashed, computesS' = sign(H))[PrKIcc]

Checks if data has been hashed

© GEMPLUS 2000


PK_OpenEnvelope

This command opens a digital envelope and returns the session key found in the envelope in plain text.

This command therefore receives an encrypted session key (using the RSA encryption algorithm) and returns the decrypted session key, if the length is correct.

The length of an extracted session key is less than or equal the value of MaxSessKey. The only limitation there is in terms of envelope size is that it must be equal to the modulus length of the selected PK file.

Format

Where:

To be able to use the raw format, the value of MaxSessKey (located in EFMaxSessionKey) must be greater or equal to the modulus length of the selected PK file.

Use the Get Response command to retrieve the value of the key.

CLA INS P1 P2 Lc Data Le

80h 1Ch RFU Padding Lc Data 00h

Padding specifies the padding format as follows:

00h PKCS#1 padding convention [00 02 PS PS...PS 00 SK SK ... SK]

Where:

PS is Padding String

SK: is Session Key

FFh Raw envelope (no padding)

Lc specifies the modulus length of the selected PK file as follows:

40h 512-bit session key

60h 768-bit session key

80h 1,024-bit session key

Data is the encrypted envelope. The data must be given with the LSB first.

© GEMPLUS 2000


new an ssing

is tored sing a

th

Response

Where:

Conditions of Use and SecurityA Select Crypto Context command must have been issued previously to select a valid RSA PK file. Value 77h of the Select Crypto Context command’s parameter P2 must beused.

Context Modification after ExecutionThe PK_OpenEnvelope command automatically clears the context byte. Therefore, acryptographic context will be required. The value of the PK flags may be modified if error occurs during the unwrap process (such as a missing private element, or a mirecord).

If the decryption has taken place properly and the length of the data to be returned ≤MaxSessKey, this data is copied (LSB first) in the response area, and its length is sin the expected length counter. Consequently, the user can get the decrypted data uGet Response command.

Command Processing

Figure 53 - PK_OpenEnvelope Command Processing

SW1 SW2

SW1 and SW2 hold the status byte values returned by the card.

61hXXh stands for normal processing of the command. (XXh = lengof the data available for the Get Response command).

“Appendix B - Card Return Codes” lists the possible contents of SW1 and SW2.

ICC

(RSA Key File, Mode)

PK_OpenEnvelope

Get Response

SelectCryptoContext

.

Verifications

Deciphered data is returned

-RSA Key

If the above verifications are OK,61 XX is returned (XX is length ofavailable deciphered data)

IFD

(Padding, Encrypted Data)-Deciphering Data-Test Padding-Test Length of Data

© GEMPLUS 2000


ter

PK_Send

This command loads the external public key into the specified card file.

The card stores the external public key elements (Next, eext or vext) in a special RSA PK file or (Pext, Qext, Gext and Yext) in a special DSA file. The verification flag and the associated certification flag are cleared.

Tag0 is initialized during the personalization phase, and may not be changed using this command. This command is rejected for files used to store the Authority public key. All the tags allowed in the PK file must have been initialized (Tag_Nb, and PK elements - even if the value of these elements is zero).

The element is sent in reverse order, for example:

If the signature exponent for RSA, e is: 010203040506070809...64h,

it is sent as follows: 646362616059585756...01h.

Format

Where:

Response

Where:

Note: The PK_Send command is the only way that elements in a PK file can be updated (the AC for Write, Update and Read are locked in “Access Never” afthe personalization phase).


80h 8Ch SFI P2 Lc Data

SFI is the Short File Identifier of the PK file (b0 through b4).

P2 is the length of the PK element.

Lc for RSA is the length of the IFD PK modulus

for DSA is 42h for p, y and 16h for q, y. (See “Note on DSA” on page 4).

Data is Tag||PK element||CKS

Where:

Tag is (n, v or e) for RSAis (p, q, g, y) for DSA

CKS is computed in the same way as for Load Private Key.

SW1 SW2


© GEMPLUS 2000


PK

ss

PK_Sign

This command signs hashed data in the card using the PrKCa (RSA: exp s or Crt / DSA: exp xsign). (See “Note on DSA” on page 4.)

This command follows the cryptographic protocol.


• The Select Crypto Context command must have been issued to set the context (file selection, algorithm and hash function selection, operation mode selection).

• The Put Crypto Data or Init Hashed Data command must have been used to put and define the data to be signed (according to a template).

If hashed data is available and the context is selected correctly, the signature proceworks.

Format

Where:

Response

Where:

CLA INS P1 P2 Le

80h 86h 00 Padding Le






Le is the length of the PK modulus for RSA

is the length of R and S concatenated (28h) for DSA.

Note: A DSA signature is composed of two parts, R and S. R isused in the computation and verification of S.

Signature SW1 SW2

Signature is the signature of the data.


© GEMPLUS 2000


Command Processing

Figure 54 - PK_Sign Command Processing

Select Context (SFI_card,Mode )

Template to describe the signed dataPut Crypto Data Data

Computes H =hash(Data)

Data may be internal card data or external data

PK_Sign

S'If hashed, computes S' = sign(H))[PrKIcc]

Normal Signature ProcessChecks if data has been hashed

Init Hashed Data

OrData already hashed by the terminal, loaded inthe card before signing with RSA algo.

H=DataCorresponds to the hash function selected

Checks the file type accordingto the mode

ICC

PuKIcc, PrKIcc, CertIcc

PuK_CaPuKIFD(mod, exp)

IFD

PuK_Ca

© GEMPLUS 2000


a

PK

o be

status ed.

RSA.

t.

PK_Verify

This command makes the card compute a verification result of a signature using a Pkexternal (RSA: exp vext/ DSA: exp yext). It can be used in two modes:

• Verify - where a signature is verified,

• Verify Certificate - where a certificate is verified (to confirm that the public keys infile have been authorized).

This command follows the cryptographic protocol.


• The Select Crypto Context command must have been issued to set the context (file selection, algorithm and hash function selection, operation mode selection).

• The Put Crypto Data command must have been used to put and define the data thashed (according to a template) to enable the comparison.

If hashed data is available and the context is selected correctly, and the certification associated to the IFD verification key is set, the verification process can be perform

The data to be verified is sent to the card by this command.

The command works as follows:

1. A verification result is computed.

2. A comparison- between the hashed data and the verification result is done, for

- between R and verification result is done for DSA.

3. If the command is used in Verify Certificate mode, - the certification status is se

Format

Where:

Note: The in-coming data format and certificate format are given in “Appendix F -Personalization Recommendations for PK_Crypto Applications”.

Note: See the “PK_Int Auth ” on page 170 for an explanation of R.

CLA INS P1 P2 Lc Data Le

80h 8Ah Mode Padding Lc Data Le

Mode specifies the operating mode of the command as follows:

00h for Verify mode

FFh for Verify Certificate mode

© GEMPLUS 2000


Response

Where:






Lc is the length of the IFD private key for RSA(40h, 60h or 80h)

is the length of R and S concatenated (28h) for DSA.

Data is the signature or certificate (depending on the mode used)

Note: For DSA, the data is always, the concatenation of R and S, irrespective of the mode used.

Le length of the result of the verification (depends on the chosen algorithm)

Result SW1 SW2

Result result of the verification (depends on the chosen algorithm).


© GEMPLUS 2000


Command Processing

Figure 55 - PK_Verify Command Processing in Verify Mode

Figure 56 - PK_Verify Command Processing in Verify Certificate Mode

ICC


PuK_Ca

Template to describe the data which has

Put Crypto Data

been used to generate the signature.

PK_Verify ( P1=00)S

If certification status is set in EEPROM and

mod (N) and exp (v) of PkIFD are written

Select Crypto Context(SFI_verif,Mode )

.

DataComputes HH=hash(Data)

Computes VV=verify(S)[PuKIFD]Compares V&H for RSA

in a SFI_verif file

V

PuKIFD (mod,exp)

according to the mode

S=sign(hash(data))[PrKIFD]

If SFI_verif file corresponds tothe mode, it's OK

if key elements (mod, exp) are inSFI_verif file

V is sent by the cardIf OK,

Compares V&R for DSA

IFD

PuK_Ca

ICC


PuK_Ca

PK_Send (SFI_verif, PuKIFD)N, v

Put Crypto Data

Cert_IFD

mod (N) and exp (v) are written


Cert_data

in a SFI_verif file

PK_Verify ( P1=FF)

mod (N) and exp (v) are validated and may be used

Computes VV=verify(Cert_IFD)[PuK_Ca]

compares V&H for RSA

V is sent by the card

V

Where Cert_IFD=sign (hash(Cert_Data))[PrK_Ca]

described by means of templates

is stored in IFD applicative database.

compares V&R for DSA

(SFI_auth,Mode )

Computes HH=hash(Cert_data)Template to describe the data

which has been used to generate the certificate.

The Public Key is referencedusing SFI_verif where, for example,Cert_data= ( Id||DATA||reverse N||reverseV)

IFD

PuK_Ca

If OK, certification status is set in EEpromin Tag0 of the SFI_verif file

© GEMPLUS 2000


PutCryptoData

This command puts (loads) and hashes data into the card before cryptographic commands and gives processing information to the card. The data must be sent in a TLV encapsulation.

A SelectCryptoContext command must be issued prior to this command in order to set the context byte. It is this byte that indicates how the data will be treated.

Format

Where:

Data StructureThe data to be hashed is referenced or sent by means of templates.

The global structure of a template is as follows:

Note: The maximum length of the transmitted blocks is 64 bytes.

A TLV format cannot be divided over two blocks otherwise data may be loaded incorrectly in the card.


80h DAh P1 P2 Lc Data

P1 contains chaining information as follows:

01h First block

00h Next block

10h Last block

11h Single block

Note: The card only checks b0 and b4 to interpret the chaining information given in P1.

P2 length of the whole block

depends on the data, limited by the I/O buffer size

addressed directly or indirectly (logically) sent in TLV format

Lc

Data

Tag: Adressing Mode Ln: Length Vn: Value

Tag = 55h Direct addressing

Ln holds the length of the data to be sent

Vn holds the data

© GEMPLUS 2000


e

Different PK elements are accessible by this Tag in an IFD public file, PK_vrf:

See “Note on DSA” on page 4.

Example:

For one block:

This block is made up of 14 bytes:

=>8 bytes are direct data sent to the card

=>64 bytes are card data (in PK files in EEPROM)

After the template interpretation, the order of the data is as follows:

0102030405060708//Modulus N in local PK file SFI 05h

The data to be sent in this case is:

Tag = A1 logical addressing (address of the current PK verification key element)

Ln holds the length of the PK element

Vn is made up of two bytes. The first byte holds the Tag_nb value of the PK element. The second byte holds the SFI of the PK file where the public key has been stored (see “ PK_Send” on page 174).

• RSA the modulus N

the public exponent for verification, V

• DSA the prime P

the subprime Q

the base G

the exponent Y

Note: By using Tag = A1h, only key elements in public key files (FDB = 2Ch) can baddressed. Otherwise, the card will not find the referenced non-crypto file.

All the data sent by the PutCryptoData command is transmitted through templates.

More than one TLV template can be sent in each block, provided they are complete (that is, L and all of v are present).

Tag 55h Ln 08h Vn 01h/02h/03h/04h/05h/06h/07h/08h

Tag A1h Ln 40h Vn Tag_nb (N)01h

SFI000101

© GEMPLUS 2000


” in

SelectCryptoContext

This command selects the RSA or DSA key, and sets options and a “Context Statusthe card. This status is verified each time a cryptographic command is processed.

The different operation modes are as follows:

Signature, Verification, Internal Authentication or Unwrap, combined with one of thefive processes (RSA/MD5, RSA/SHA, DSA/SHA, RSA/SSL, RSA unwrap).

Format

The operation modes are implemented as described here:

X: Not available

* These modes are only allowed if the DSA algorithm is present on the card and has been activated. See “Note on DSA” in the chapter, “Overview”.

Response

Where:

CLA INS P1 P2 Lc

80h A6h SFI Operation mode 00h

RSA& MD5

RSA& SHA

DSA& SHA

RSA& SSL

DES RSA Unwrap

PK_Sign 11h 12h 13h* 18h X X

PK_Verify 21h 22h 23h* X X X

PK_Int Auth 31h 32h 33h* 38h X X

PK_OpenEnvelope X X X X X 77h

Table 40 - Operation Modes for SelectCryptoContext Command

SW1 SW2


© GEMPLUS 2000

© GEMPLUS 2000

A
The Default Answer To Reset
ics of

dard

When a terminal powers up a GPK card, it responds by returning a standard Answer To Reset (ATR) at 9600 Bauds. The terminal can retrieve additional information using the Get Response command.

GPK’s Answer To Reset is compliant with the ISO 7816 standard.

Interface characters specify physical parameters of the card and logical characteristthe subsequent exchange protocol.

Historical characters designate general information implemented by the card manufacturer. The specification for these characters is outside the scope of the stanspecifications.

The ATR of GPK cards can thus be modified by Gemplus according to the card features. Future card versions or chip sources may require that these characters be changed.

Application software must not reject a card on the basis of a given ATR (to allow the use of future card versions).

However, it should be noted that a specific ATR can be customized to meet your requirements. Please contact Gemplus for more information.

186 The Default Answer To Reset

The FMN and PRN can be used to identify a card as GPK regardless of the EEPROM size, O/S version or chip type.

Character Type

Byte Value Description

Initial and Format

TS 3Bh Bit synchronization and structure, direct convention

T0 A7h TB1 present, TD1 present, seven historical bytes

Interface TB1 00h Vpp not present

Vpp not connected

TD1 40h TC2 present

TC2 18h Work waiting time, ETU = 360 X 18h

Historical T1 80h Category indicator (status information in compact TLV object)

T2 65h Compact TLV for “Pre-issuing Data”

T3 A2h Family Name (generic Gemplus products).

T4 08h

09h

GPK8000

GPK16000

T5 01h OSV Operating system version (reserved Gemplus)

T6 01h Program version (reserved Gemplus)

T7 52h Chip Identification Value (reserved Gemplus)

Table 41 - Answer To Reset

Caution: The Chip Identification value shown (T7) is an example of a chip that is used by Gemplus. This value may be changed without prior notification if Gemplus uses chips from other suppliers in the future. Therefore it is not recommended to use the CIV to identify a card.

© GEMPLUS 2000

© GEMPLUS 2000

B
Card Return Codes
sent

data

nt

on

hed

This appendix lists and describes the card status codes or “status bytes” that can beback by GPK cards in response to a command.

Transmission protocol related codes SW1 = 6xh:

61 nnh Command processed without error. The command prepared nn bytes of that can be retrieved using the Get Response command

61 03h Command using secure messaging processed without error. Three-byteacknowledgment cryptographic checksum is available

62 81h IADF error - a problem occurred during IADF interpretation and the relevadata may be corrupted

62 83h Warning: Invalid DF

62 84h File descriptor error

63 00h Authentication failed

63 Cnh Incorrect secret code submission. 'n' represents the number of tries left

64 00h Wrong context (for PK Crypto commands)

65 81h Write problem / Memory failure (ISO class byte)

67 00h Incorrect length or address range error

69 00h No successful transaction executed during session

69 81h Cannot select indicated file, command not compatible with file organizati

69 82h Access conditions not fulfilled:

Secure messaging required and no key specified in Access Conditions

Secure messaging required and no temporary administration key establis

69 83h Secret code locked

69 84h Not enough memory space in the file

69 85h No currently selected EF, no transaction manager file (for Select Purse & Key)

6A 80h Incorrect parameters in data field (Create File command)

188 Card Return Codes

Application related return codes SW1 = 9xh

6A 81h Invalid function

6A 82h File not found

6A 83h Record not found

6A 84h Not enough memory to create file or append record

6A 88h Key selection error (file not found, descriptor error, file is not a key file, key type error)

6B 00h Incorrect reference (address, number, or segment); illegal address

6C nnh Communication buffer exceeded; where nn is the maximum command length in the case of outgoing commands without secure messaging

6C 40h Wrong length (in secure messaging mode)

6D 00h Command not allowed

6E 00h Incorrect application (CLA parameter of a command)

90 00h Command executed without error

91 00h Purse Balance error (insufficient or exceeded) cannot perform transaction (for Cancel Debit command this corresponds to an abort)

91 02h Purse Balance error occurred during the replacement debit step of a Cancel Debit command

94 04h Purse selection error or invalid purse (for Cancel Debit command this is in the cancellation step)

94 06h Invalid purse detected during the replacement debit step of a Cancel Debit command

94 08h Key file selection error for example, file not found, offset incorrect, descriptor error, or specified file not key file)

98 04h Access authorization not fulfilled, wrong certificate, key file, or TTC

98 06h Access authorization in Debit not fulfilled for the replacement debit step of a Cancel Debit command

98 20h No temporary transaction key established (for Cancel Debit this means there was no temporary transaction key established or the debit certificate has already been retrieved)

© GEMPLUS 2000

© GEMPLUS 2000

C
Examples of Implementation of EMV-Compatible Feature
tem

ata

File StructureTo ensure compatibility with EMV specifications, the mapping of the card must include the structure of the payment system environment as follows:

• The Payment System Environment DDF (Directory Definition File) called '1PAY.SYS.DDF01' (name defined according to the EMV IC Card Payment SysSpecifications)

• The Payment System's Directory EF, containing the entries to the Application DFiles (ADFs) held in the card.

The following figure outlines the file structure for payment systems:

Figure 57 - File Structure For Payment Systems

Note: For further information, refer to the EMV IC Card Specifications for Payment Systems, Parts 1, 2 and 3.

File to be completed with the

ADFs entries held in the card

Directory EF

0201

Directory EF

Master File

3F00

1PAY.SYS.DDF01

DDF (0200)

190 Examples of Implementation of EMV-Compatible Feature

This architecture is normally created during personalization. See “GPK Personalization” on page 196.

The GPK card mapping also includes the ADFs, referred to in the Payment System Directory, that hold the EFs of data dedicated to one application.

Each DF must contain at least one system file called FCI (File Control Information) EF, that is needed to process the Select File command. This file is an IADF and must therefore be created using the structure described for IADFs in “Internal Application Data File (IADF)” on page 35.

.

Figure 58 - GPK Card Mapping

Payment System Environment DDFTo ensure compatibility with EMV specifications, this DDF is mapped onto a DF called ’1PAY.SYS.DDF01’ (identifier 0200h).

This DDF contains the Payment System Directory EF (identifier 0201h) described in the next section.

ADF and EF to be created and initialized

ADF1 Name

ADF Name

ADF2 Name

0201021F

041F 0401

0301 0302031F

0X1F

FCI system file

FCI EF

Data File Data File

ADF1 (0300)

Data File

ADF

ADF2 (0400)

Directory EF

FCI EF

FCI EF

FCI EF

xxxx

EF

DDF (0200)

1PAY.SYS.DDF01

Master File

3F00

021F

FCI EF

© GEMPLUS 2000

Examples of Implementation of EMV-Compatible Feature 191

”) the

Payment System Directory EFThis is a linear and variable record EF. It can consist of a single record. Its SFI (Short File Identifier) must be coded between 1 and 10. This SFI will be stored in the Payment System DDF FCI, and retrieved using the Select File command.

The Payment System Directory contains entries to the ADFs in the card. Each ADF entry in a Payment System directory is encapsulated in an Application Template (tag “61h(see the following table) coded within a record, and holding information according toADF Entry TLV’s table.

Application PriorityWhere the Application Priority byte is present, it is coded as follows:

Tag Length Value

61h var. ADF Entry TLV’s

Table 42 - ADF Entry Encapsulation, to be applied to each ADF

Tag Length Value Presence

4Fh 5-16 ADF name (AID) Mandatory

50h 1-16 Application Label Mandatory

9F12h 1-16 Application Preferred Name Optional

87h 1 Application Priority Optional

Table 43 - ADF Entry TLV’s

Note: This is an example. Additional TLVs are described in the EMV IC Card Specifications for Payment Systems, Parts 1, 2 and 3, and can be implemented in GPK cards.

Bit 7 Determines if application selection requires cardholder confirmation

1b Application selection requires cardholder confirmation

0b Application selection does not require cardholder confirmation

Bits 6-4 RFU

Bits 3-0 0000b No priority assigned

xxxxb Priority order in which application is to be listed or selected, ranging from 1 to 15, with 1 being the highest priority.

Table 44 - Application Priority Byte

© GEMPLUS 2000


is t

the

ns

ent

ed in

of ist’

DFs

ation

Payment System Application Identifiers (AID)The structure of the Application Identifier (AID) is defined in the ISO 7816-5 standard, and consists of two parts:

• A Registered Application Provider Identifier -RID- (five bytes) specific to a given application provider, and assigned according to ISO 7816-5.

• An optional field of up to 11 bytes and assigned by the application provider. Thisfield is known as a Proprietary Application Identifier Extension, PIX and may contain any 0-11 byte value specified by the provider. The meaning of this field defined only for the specific RID and does not need to be unique across differenRIDs.

Application Data Files (ADFs)An ADF contains the data that the card stores for a given application.

The ADFs are mapped onto a DF, whose name is coded in the Payment System Directory EF according to the format described in the previous section.

Implementation in the TerminalThis section briefly describes how commands and the mandatory data previously described would be implemented by an EMV terminal to execute a transaction with GPK card.

Use of the Payment System DirectoryIn compliance with EMV specifications, a terminal supporting a large number of applications may use the Payment System Directory EF to determine the applicatiosupported by the card.

1. The terminal begins with an explicit selection of the Payment System EnvironmDDF using the Select File command and the file name '1PAY.SYS.DDF01'.

2. The terminal reads the Payment System Directory EF whose SFI has been codthe File Control Information retrieved during the previous Select File command.

3. If the name of an ADF stored in the Payment System Directory EF matches onethe applications supported by the terminal, this application joins the ‘candidate lfor the final application selection.

4. When the terminal completes the list in the Payment System Directory EF, all Aheld in the card will have been defined. The search is complete.

Selecting the Application to Be RunOnce the terminal determines the list of mutually supported applications, it must determine the single application to be run.

The terminal either displays the list to the cardholder and who then selects the applicor else it will select the highest priority application from the list of mutually supportedapplications.

© GEMPLUS 2000


Bit 7 of the Application Priority byte determines which of the above methods is used. Bits 3-0 contain the priority number (where 1 is the highest priority).

Once the application to be run has been defined, the application must be selected, using the Select File command. The figure below illustrates the sequence of commands used to select an application using the Payment System Directory.

Figure 59 - Selecting an Application Using the Payment System Directory

At this point, the terminal processes the transaction by using the functions implemented for the selected application.

CardTerminal

FCI (...,SFI Payment System Directory EF, ...)

( ADF1 name -AID1-, ..., ADF2 name -AID2,...)

[Select ADF ]

'1PAY.SYS.DD01'

[Get Response ]

[Get Response ]

[Read Record]SFI Payment System Directory EF

[Select PSE DDF]

ADF name

FCI (...,SFI Payment System Directory EF, ...)

© GEMPLUS 2000


tain

Examples of Implementation in CardsThis section describes two examples of implementation of the GPK card.

The first example consists of a single E-Purse application implemented in the GPK card.

The second example consists of implementing the GPK card in a multi-application context: one is an Electronic Purse application, the other is an EMV-compatible application.

Single Application Context: E-PurseIn this example, the GPK card only holds a private E-Purse application, which is implemented in an ADF. Only the application selection can use the EMV functions. For the rest of the transaction, the card makes use of the GPK payment functions.

The Payment System Directory EF only contains the E-Purse application AID and its related label, coded according to the rules described earlier in this appendix. It will be one of the following:

• the AID of the E-Purse Application Provider AID, registered to ISO.

• a concatenation of the Gemplus RID (assigned according to ISO), and a PIX identifying precisely the given application.

Finally, the Payment System Environment DDF, and the E-Purse ADF will both conan FCI file so that they can process the Select File command.

Figure 60 - Files Structure for E-Purse Single Application Context

FCI EF

021F

Directory EF

0201

Master File

3F00

DDF (0200)

1PAY.SYS.DDF01

EPurse ADF (0300)

AIDFCI EF

031F

Purse EF

0301

© GEMPLUS 2000


each

Multi-Application ContextIn this example, the GPK card can hold several applications including:

• A private Electronic Purse application

• An EMV-compatible application using a single record.

Each of these applications will be implemented in a separate ADF.

The Payment System Directory EF will contain:

• The E-Purse application AID and its related Label, coded according to the rulesdescribed earlier in this appendix.

• The EMV application AID and its Label.

The Payment System Directory EF could optionally store the Priority byte related to application.

The Payment System Environment DDF, the E-Purse ADF and the EMV applicationADF will all contain an FCI file, so that the Select File command can be processed.

Figure 61 - Files Structure for E-Purse Multi-Application Context

3F00

1PAY.SYS.DDF01

ADF Name

031F 0301

041F 040n

"Application ID"

021F

FCI EF

0201

Directory EF

Master File

DDF (0200)

Purse File

EPurse ADF (0300)

FCI EF

Appli EF'sFCI EF

EMV application

© GEMPLUS 2000


V

sing

the

d as a

GPK PersonalizationThis section draws the developer’s attention to the elements that must be taken into account in order to personalize the GPK cards correctly.

The personalization process will initialize the EMV memory structure, as well as cardholder-related programming data. This takes into account the DDF, the Payment System Directory EF and the ADF(s) initialization in accordance with the rules already described in this appendix.

Create DDF and ADF(s)Use the standard GPK Create File command with the appropriate options to create the Payment System DDF and an ADF for each application.

Create FCI FilesIn order to make a DF accessible by the Select File command, you will need to create an FCI EF under that DF. You must therefore create an FCI EF for the DDF and for each ADF.

You will use the standard GPK Create File command, but with “09h” as the FDB value, and “nn 1Fh” as the file identifier value (where nn are the first two digits of the DF identifier).

The length of the FCI file will take into account the overhead associated with the TLcoding.

Fill FCI FileOnce created, the FCI EF needs to be completed with the relevant information by uthe standard GPK Update Binary command.

The DDF FCI FileThe DDF FCI file must be completed with the DDF Name, '1PAY.SYS.DDF01' and SFI of the Payment System Directory EF, '01h'.

The data is encapsulated in a template with a '6F' Tag and a Length. It is then codeTag Length Value constructed data object, as follows:

Tag Length Value

6Fh var FCI Template

84h 14 1PAY.SYS.DDF01

A5h var FCI Proprietary Template

88h 1 SFI of the Payment Directory EF

© GEMPLUS 2000


The following is an example of personalization: (all values are in hexadecimal)

The ADFs FCI filesThe ADF(s) FCI file(s) must be completed with the ADF Name and the Application priority Indicator.

The data will be encapsulated in a template with a Tag ’6Fh’ and a Length, and coded as a Tag Length Value constructed data object, with the following Tags:

An example of the contents of an ADF FCI EF data field is provided as follows (all values are in hexadecimal):

1A 17 55 17

6F 15 84 0E

31 50 41 59

2E 53 59 53

2E 44 44 46

30 31 A5 03

88 01 01

Tag Length Value

6Fh var FCI Template

84h 5-16 DF name

A5h Var FCI Proprietary Template

87h 1 Application Priority Indicator

13 10 55 10

6F 0E 84 07

Application Identifier

A5

03 87 01 00

© GEMPLUS 2000


Create the Payment System Directory EFUse the standard GPK Create File command with the appropriate options, notably with ’05h’ as FDB value, reserved by ISO for an EF with linear variable record structure, and supporting a simple TLV template.

Once created, the structured file should be completed with the appropriate data. Use the Update Record command to create the record structure and record data field, according to the following figure:

Fill the Payment System Directory EFThis file must be completed with the entries to the ADFs held in the card, as described in “Payment System Directory EF” on page 191: the AID(s), the Label(s), and optionally the Application Preferred Name(s) and the Application Priority Indicators.

The data is encapsulated in a template with a ’70h’ Tag and a Length. It is then coded as a Tag Length Value constructed data object, with the following tags:

The following is an example of a Payment System Directory EF data field format, containing the entries to the Electronic Purse application (all values are in hexadecimal):

Record Length (1-255)

Record Template

Tag Length Value Presence

4Fh 5-16 ADF name (AID) M

50h 1-16 Application Label M

9F12h 1-16 Application Preferred Name O

87h 1 Application Priority O

13 70 11 61

0F 4F 07

Application Identifier

50 04

Application Label

© GEMPLUS 2000

© GEMPLUS 2000

D
Applicative PK File Organization
This diagram shows a proposed organization for a PK-crypto file architecture where the card is used as a tamper-proof safe for the private card holder key, and as a cryptographic calculator for terminal PK processes.

Secret codes are used to secure the link between the card and the card holder so that pin verification ensures valid authentication.

Figure 62 - Proposed PK File Organization

ApplicationNo. 1

Card DSAFile

Master File

SecretCode File

Terminal DSAFile

Card DESFile

Authority DSAFile

Card RSAFile

Terminal RSAFile

ApplicationNo. 2

Authority RSAFile

Note: GPK supports file selection by file identifier, Short File Identifier and only for DF by partial name. See “ Select File” on page 111.

© GEMPLUS 2000

E
GPK Life Cycle
1. once

ssing

o the g the

e

m the

SC. In the

GPK cards have a four-phase life cycle as follows:

• Phase 1: blank chip

• Phase 2: card initialization

• Phase 3: card pre-personalization

• Phase 4: card personalization

Each phase is initiated by setting one of three specific bits in the lock byte from 0 toSetting one of these bits is irreversible, thus, you cannot return to a previous phaseyou have set the appropriate bit.

This section describes these phases, and summarizes the card state and the proceperformed in each.

Blank Chip PhaseThis phase covers the time from the manufacture of the chip and its transportation tcard manufacturer. During this phase, the chip memory can be freely accessed usinRead Memory and Update Memory commands. During this phase, the chip manufacturer writes the Chip Serial Number and Transport Secret Code (TSC) to thchip.

Before the chip leaves the foundry, to be delivered to the card manufacturer, it is protected by the TSC, that is the TSC must be presented correctly in order to perforRead Memory and Update Memory commands.

Card Initialization PhaseThe chip is now embedded in the card, and access to the chip is protected by the Tthis phase the card manufacturer performs card initialization tasks such as creatingGPK system files and testing the EEPROM.

At the end of this phase, the system files are locked and the Read Memory and Update Memory commands can no longer be used.

202 GPK Life Cycle

Card Pre-Personalization PhaseThis phase covers the time between the card issuer receiving the card and distributing it to the end user. In this phase the file management commands are available and can be protected by secure messaging. The issuer can download any application data and references required by the application to the card memory.

Card Personalization PhaseThe card enters this phase when it is personalized and passed on to the end user. In this phase the Read Memory and Update Memory commands are no longer available. The Read Binary command is still available to read the Card Serial Number and Gemplus Issuer References.

You must set the Bissuer bit in the lock byte to enter the applicative step.

© GEMPLUS 2000

© GEMPLUS 2000

F
Personalization Recommendations for PK_Crypto Applications
PK Command Data InversionThe cryptographic calculations require that data stored in the EEPROM and in the RAM buffer are always stored with LSB in the lowest address.

This technical requirement is not catered for by the card and leads to some applicative constraints on the following commands: the data must be inverted byte by byte to replace the MSB by the LSB.

Incoming Data / Special Data InversionLoad Private Key

PK_Send

PK_Verify

=>In: PLAIN: Tag || Inverted Private Element || CKS

ENCRYPTED[Kt]: DES(Tag || Inverted Private Element || CKS || Padding to make total size a multiple of eight bytes)[Kt]

=>In: Tag || Inverted Public Element || CKS

=>In: DSA=> Inverted R || Inverted S

RSA=> Inverted S

204 Personalization Recommendations for PK_Crypto Applications

)

PK_Verify (in “Verify Certificate” mode)

Append Record on PK file

Update Record on PK file

InitHashedData

Outgoing Data Special Data InversionPK_Int Auth

PK_Sign

PK_Verify

ReadRecord on PK file

=>In: The PK elements referenced through the Template Tag 'A1h' are read in thesame order as they were written during the personalization phase, that is, INVERTED.

This means that the certificate must be in a special format if the certification process is to succeed: THE PK ELEMENTS (n,v) and (n,e) for RSA, (p,q,g,yfor DSA MUST BE SIGNED INVERTED, to constitute the certificate (Authority signature).

=>In: Tag || Inverted Public Element

=>In: Tag || Inverted Public Element

=>In: Inverted MD5 || Inverted SHA in SSL mode (18h, 38h)

=> Inverted MD5 in MD5 mode (11h, 31h)

=> Inverted SHA in SHA mode (12h, 32h, 13h, 33h)

=>Out Sign(TRnd)[SKcard]

=>Out Sign(Hash(Data))[SKcard]

=>Out Sign(TRnd)[SKcard]

DSA=> Inverted T

RSA=> Inverted V

=>Out TagInverted PK element.

© GEMPLUS 2000

Personalization Recommendations for PK_Crypto Applications 205

Personalization Scenario Example

Applicative ScenarioThe global structure for a Pk file is as follows:

Figure 63 - PK File Personalization Example

Where:

To create a similar structure, the command sequence is as follows:

End of previous file

Public file header

Lsys0 Tag0 System Record Indicates the key type, the key length, access conditions for PK commands and the certification flag.

Lsysi Tagi Public key element A record storing one public key element.

--------------------------

Lsysj Tagj Public key element Final public key element record.

Private file header The private portion is non-accessible.

Lsys0 Tag0 System Record Indicates the same information as for the public portion system record.

Lsysk Tagk Lng || Private key element

A record storing one private key element.

--------------------------

Lsysl Tagl Private key element Final private key element record.

Beginning of next file

Lsys0,i,j is one byte reserved by the operating system to store the length of the record (for example, 07h in the case of the system record).

Tagi,j is a tag for a public key element.

Tagk,l is a tag for a private key element.

1. Select File select the Crypto application (that is, the DF) (no need for an IADF in this DF unless the FCI is wanted).

2. Create File create the public body of the file of a size sufficient to store the necessary public elements => tag0 || key element (remember to include Lsys, and Tag).

3. Append Record mandatory to write Tag0 first just after the key file header.

© GEMPLUS 2000

206 Personalization Recommendations for PK_Crypto Applications

d.

.

card ten

at

4. Append Record load each key element with its specific tag in its associated record (repeat the process as many times as necessary to load the key elements used for the crypto commands of the application).

5. Freeze AC optional; it depends on your application. It is advised to lock Write and Update either with a strong AC or set access to “never” to prevent a key being forged during the life of the car

6. CreatePrivateKeyFile

create the private body of the file of sufficient size to store allthe private elements.

tag0 || key element. Remember to include Lsys, Tag, and theprivate key elements. Remember also that the private key elements are:

Lg || Private key element (as shown in the figure “PK File Personalization Example”).

The total size of the private portion of the file (not including theprivate file header) must be a multiple of four.

7. Select File Key generate a temporary session key.

8. Load Private Key load private key elements ensured of integrity and confidentiality.

Note: There is no need to load a Tag0 in the private body of the file; Tag0 is copiedfrom the public portion to insure homogeneity of the whole set of public keys

Caution: For PK Authority Files:

These files are used to store the Authority’s set of public keys.

The records containing the key elements must be loaded once during thepersonalization phase. This file is readable but cannot be updated or writto unless there is a strong AC attached to the file.

These PK-files are identified in the card by the “Rights” byte (No.4) of thesystem record (Tag No. 0). It is the 2 Type bits (Typ1Typ2) of this byte thidentify a file as a PK Authority file.

Since the Authority PK set of keys cannot be certified by the card, the bitCert in the “Rights” Byte (B4) must be set to '1' during personalization.

© GEMPLUS 2000

Personalization Recommendations for PK_Crypto Applications 207

tem

t

.

Reminder of System Record (Tag 0) and B4:

This first record, seven bytes long, identified with Tag_Nb = “00h” describes this sysinformation.

Where:

B6 B5 B4 B3 B2 B1 B0

Tag_Nb Klgth Rights Access Conditions RFU Algo Cks

Note: This information is used in the SelectCryptoContext command.

Rights is coded as follows:

b7 b6 b5 b4 b3 b2 b1 b0

Val1 Val2 Typ1 Typ2 RFU RFU RFU Cert

Val1Val2 00b Not protected by secret code

01b Protected by SC1 (a secret code - see “Access Conditions” description that follows)

10b Protected by SC1 and SC2

11b Access is never

Typ1Typ2 00b Signature and unwrap key

01b Signature key

10b Unwrap key

11b Designates key as an Authority file, locked in ‘Write’ and ‘Update’, after the personalization phase. This is used to protecthe Authority’s public key and prevent it from being overwritten by a PK_Send command (the PK_Send command checks these bits and does not overwrite the key elements if they are set to 11b). See “ PK_Send” on page 174 for more information.

Cert 0b Public key elements have not been certified

1b Public key elements have been certified, that is, signed by a CAThis bit is set for:

- Authority PK files during the personalization phase.

- PK files after a successful certificate verification.

© GEMPLUS 2000

Terminology

Abbreviations

AC Access Condition

ANSI American National Standards Institute

APDU Application Protocol Data Unit

ATR Answer To Reset

CBC Cipher Block Chaining

CDC Card Debit Certificate

CHV Card Holder Verification

CKS Checksum

CRnd Card Random Number

CRT Chinese Remainder Theorem

CRYCKS Cryptographic Checksum

CSC Card Signature Certificate

CSN Card Serial Number


DES Data Encryption Standard

DF Dedicated File

DSA Digital Signature Algorithm

EAC External Authentication Cryptogram

ECB Electronic Codebook

© GEMPLUS 2000

210 Terminology

EF Elementary File

EMV Europay Mastercard Visa

FCI File Control Information


GPK Gemplus Public Key

IAC Internal Authentication Cryptogram

IADF Internal Application Data File

Id Identifier

IFD InterFace Device

ISO International Organization for Standardization

lsb least significant bit(s)

LSB Least Significant Byte(s)

MD5 Message Digest version 5

MF Master File

msb most significant bit(s)

MSB Most Significant Byte(s)

OS Operating System

PK Public Key

PKCS Public Key Cryptography Standard

RFU Reserved for Future Use

RSA Rivest, Shamir and Adleman (creators)

SCR Secret Code Ratification counter

SDC Cancel Debit Cryptogram

SFI Short File Identifier

SHA Standard Hash Algorithm

SK Session Key

SSL Secure Socket Layer

TLV Tag, Length, Value

3DES Triple DES

TRnd Terminal Random Number

TS Initial character in the ATR

© GEMPLUS 2000

212 Terminology

y g,

.

s

Glossary


Stored in the variable part of a DF or EF file descriptor, this specifies the number and level of the secret codes referred to by the Group AC part of an access condition.

See the entries for “Group AC” and “Access Conditions”.

Access Conditions Access conditions refer to three functional groups, related tooperations on a file (for example, update, read). These operations differ for DFs and EFs.

The access conditions determine how many and which secret codes are used to protect a file for each group. If a keis to be used to generate a session key for secure messaginthe access conditions give the location of the key file to be used.

Access conditions are made up of two parts:

Group AC that determines how many secret codes must bepresented (or access always denied) and the key file details

AC Secret Code Reference that identifies which secret codeare to be used

See also the entries for “Group AC” and “AC Secret Code Reference”.

Administration Commands

Commands that perform administration functions such as creating files, writing to files and reading from files.

Administration Key Type of cryptographic key used for the computation of temporary administration keys, authentication and secure messaging.

Administration Session

Session during which administration commands are performed.

Algorithm A mathematical function used to derive a new value from aninput value. Algorithms are used to encrypt, decrypt, and hash data.

Application An application makes use of security mechanisms, files, data and appreciation protocol.

Asymmetric Algorithm

See the entry, “Public Key Algorithm”.

Asymmetric Cryptography

Also known as public key cryptography. This uses public key algorithms to encrypt data.

© GEMPLUS 2000

Terminology 213

e.

Authentication Process used to verify that a terminal or card is genuine. There are two types of authentication:

Passive authentication (ISO 7816-4 password presentation): which always uses the same values (for example a Card Holder Verification (CHV) code).

Active authentication (ISO 7816-4 key presentation): which uses a random number, an algorithm and a secret key (or a random number, PK algorithm and public key) to calculate a result. The same calculation is performed both on the terminal or network and on the card. If the results match, the terminal or the card is authenticated. Active authentication provides a totally transparent means of checking that both the card and the network or terminal have the same secret key.

Authorization Register

Eight-bit RAM register that keeps a record of the secret codes that have been successfully submitted. GPK compares the contents of the register with a file’s access conditions toestablish whether or not access should be granted to that fil

BER Encoding Basic Encoding Rules. A set of rules determining how abstract objects can be coded in binary. There is usually more than one way to BER-encode a value.

Cancel Debit Cryptogram (SDC)

This is calculated by the terminal and sent to the card duringa cancel debit transaction. It is used to verify that the terminal is the one that was used to perform the original debit transaction.

Card Debit Certificate

A certificate calculated and issued by the card to authenticate a debit or cancel debit transaction.

Card Session A link between the card and the interface device starting with the Answer To Reset and ending with a subsequent reset or a de-activation of the card.

Card Transaction Counter (CTC)

Three-byte counter that the card increments each time a payment session is executed that is, each time that the Select Purse & Key command is executed. GPK uses the Card Transaction Counter when it computes the temporary transaction key.

© GEMPLUS 2000

214 Terminology

Certificate The GPK system generates certificates after performing certain transactions such as reading a purse balance or debiting a purse. They confirm the authenticity of a transaction. You may use such certificates at a later date to verify a transaction.

In public key cryptography, a certificate is the signature of public keys in a card using data encrypted by the private key of the certification authority.

The data certificate can, if required by the customer, be compliant with the X509 standard so the public key value is already included in the certificate.

example: Cert = Sign(Identity || Public key || Expiry date)

Cipher Block Chaining (CBC)

A mechanism used to cipher blocks of data, in which the results of the encryptions of previous blocks are fed back into the encryption of the current block.

Compressed Data Data that has been reduced in size as the result of a hashing algorithm (MD5 or SHA) or by the SSL protocol.

Context Information on the type of key (RSA or DSA - if implemented), the key length (512, 768 or 1,024 bits) and the hashing algorithm. This information is stored by using flags in RAM. A context is defined by using the Select Crypto Context command.

Credit Cryptogram (CC)

The credit cryptogram is generated by the host or terminal to authenticate a credit transaction. The card makes its own calculation and if the two match, the balance in the card is updated.

Credit Key Key used by the Credit command to generate the temporary credit key.

Cryptographic Checksum (CRYCKS)

Used to insure integrity in secure messaging.

Cryptography The process of keeping data or messages secure.

Current Directory The last directory (MF or DF) selected in the card.

Current EF The last EF selected in the card.

Current File The last entity selected in the card (DF if no EF is selected, EF if an EF has been selected).

Customer Key Card

The card that holds the mother system key for batches of cards. A customer key card is valid for 12 months (by default) from its date of issue.

© GEMPLUS 2000

Terminology 215

Data File An EF containing data that is not interpreted by the operating system. These files are recognized by the OS using bits 3 through 5 of the File Descriptor Byte (FDB). Such a file is defined with b5b4b3 equal to 000. Data files can be transparent files, or structured files (linear fixed files, linear variable files, and cyclic files).

Data Unit The smallest set of bits that can be unambiguously referenced.

Decryption The transformation of encrypted code into plain data.

Dedicated File (DF) File that holds groups of EFs.

DER Encoding Distinguished Encoding Rules. A subset of BER.

DFSystem This is the DF beneath which the system Elementary Files are stored. The system Elementary Files are: EFCard, EFIssuer, EFSystem and EFMaxSessionKey.

Digital Envelope This is used to “wrap” data. A digital envelope consists of two parts: an ordinary slot including data ciphered with a symmetric key, and an additional slot including this symmetric key ciphered using the RSA public key of the receiver.

Direct Addressing See “Direct Data”.

Direct Data This is data that is sent with a function or command. This issometimes referred to as direct addressing.

Directory General name for the Master File (MF) or a Dedicated File (DF).

Diversified Key Key derived from a Mother Key, an algorithm and a random number.

DSA A public key algorithm. See “Note on DSA” on page 4” .

EFCard An EF that stores the card manufacturer serial number and the Gemplus issuer reference.

EFIssuer An EF that stores the issuer serial number and the issuer reference.

EFKey An EF that holds the system key.

EFMaxSessionKey This file contains the maximum length of data that the card can unwrap.

EFSystem A system file reserved by Gemplus.

Electronic Codebook (ECB)

A mode of encrypting plain text into ciphertext.

Electronic Purse See “Purse”.

© GEMPLUS 2000

216 Terminology

Elementary Files (EF)

Part of the GPK file hierarchy; Elementary Files hold data (cf ISO 7816-4).

Encryption The transformation of plain data into ciphered data that cannot be read without the cryptographic key used to encrypt the data.

Error Condition Condition inducing rejection of a command.

Exponentiation Mathematical process used in public key algorithms that corresponds to an exponentiation and then a modular division.

M=binary message

e=exponent E = M^e mod n

n=modulus

External Authentication

Authentication of the external world (a terminal or a user) to a card. There are two types of external authentication:

Passive authentication (always the same value), for example, PIN presentation,

Active authentication (based on an algorithm and using variable values), for example, a cryptogram with a random number.

External Authentication Cryptogram (EAC)

A cryptogram used in external authentication.

File Control Information (FCI)

This information is returned after a file is selected (an Answer To Select) and includes the file’s name, type (DF orEF), level (global or local), and Short File Identifier (SFI)

File Descriptor Element generated at file creation and used by the GPK operating system to manage files.

File Identifier Part of the file descriptor. A two-byte value used to identify a file (the MF, a DF or an EF) inside a directory. The five lsb are the SFI.

GPK Gemplus Public Key (GPK) is an operating system adaptedto multi-purpose and payment applications.

© GEMPLUS 2000

Terminology 217

e

is

Group AC Stored in the fixed part of a DF or EF file descriptor, this specifies the protection to be given to a group (zero, one or two secret codes or access is never). This part of the access condition number of the secret codes used in the access condition.

If a key is to be used to generate a session key for secure messaging, the access conditions give the location of the key file to be used.

See also “AC Secret Code Reference” and “Access Conditions”.

Hashing The process whereby a variable-length input string is converted to a fixed-length (generally smaller) output string.

Indicators Internal flags recording the following:

- Whether or not the temporary transaction key has been established,

- Whether or not a debit transaction has been executed in thcurrent transaction session,

- Whether or not the command data is valid.

Indirect Addressing See “Indirect Data”.

Indirect Data This is when a function or command points to data instead of including the data directly. The “pointer” is the logical address of the file containing the data. This is sometimes referred to as indirect or logical addressing.

Initialization First stage of the card-issuing process. The main goal of thisprocess is to initialize the card EEPROM and to customize the card to a specific operator as far as administrative management of the card is concerned.

InterFace Device (IFD)

A device that sends commands to, and receives commandsfrom, the card. For example, a terminal.

Internal Application Data File (IADF)

This file determines the contents of the FCI.

Internal Authentication

Process used to prove that the card is an authentic card. It an active authentication, based on an algorithm using random values.

Internal Authentication Cryptogram (IAC)

A cryptogram used in internal authentication.

Internal EF EF for storing data interpreted by the card.

© GEMPLUS 2000

218 Terminology

f

ISO 7816 The International Standard for “Information Technology - Identification Cards - Integrated Circuit(s) cards with Contacts”.

ISO 9796-2 An ISO-defined padding used by GPK.

Level Number of DFs in the path to a file, starting from the MF (MF level=1).

Lock Byte A specific byte that indicates the following:

Whether or not the Double Reset Mechanism is enabled

The data units in the card (one or four-byte units)

Whether or not the DSA algorithm is present

When personalization has been completed.

Log Key Type of payment key that can be used for the computation otemporary payment keys and for the secure messaging process. The log key cannot be used to compute temporaryadministration keys.

Logical Addressing See “Indirect Data”.

Master File (MF) This is the root of the GPK file structure. The MF is also a dedicated file (see ISO 7816-4).

Message A string of bytes transmitted by the terminal to the card or vice-versa, excluding transmission-oriented characters.

Message Digest 5 (MD5)

A hashing algorithm used in GPK.

Mother System Key The key from which the System Key for each card in a batchof GPK cards is derived. It is stored in the batch card that corresponds to the batch of GPK cards.

OTP Memory One-time programmable area in the card’s memory, that is,it is irreversible.

Parent File The MF or DF immediately preceding a given file within the hierarchy.

Payment Command Cryptograms

Payment Command Cryptograms (PCCs) are generated byGPK cards and terminals during payment transactions and can be used to verify the integrity of transmissions.

Payment Key GPK cryptographic key used for payment commands such as temporary certification key computation.

Payment Session Session during which payment commands are performed.

Personalization Second stage of the card-issuing process. In this step the card is personalized with card holder-related information and the supplementary service combination (for example, holder name, numbers).

© GEMPLUS 2000

Terminology 219

Personalization Center

Center in which the following functions are performed:

- Card programming

- Data connection to the subscription management system.

PK File A Public Key file. A file containing public and private key elements.

PKCS#1 A type of padding used by GPK.

Private Key The part of a PK file that is not accessible or readable. The private key is made up of private key elements that are used for internal authentication or signatures.

Public Key The part of a PK file that is accessible and readable. The public key is made up of public key elements that are used for verification and encryption.

Public Key Algorithm

Also known as asymmetric algorithm. This uses different keys to encrypt and decrypt data. Furthermore, the decryption key cannot be calculated from the encryption key.

GPK uses the RSA algorithm. It is feasible to implement the DSA algorithm, see “Note on DSA” on page 4.

Purse A conceptual entity with which financial transactions are performed. See document entitled Electronic Purse architecture for MPCOS-EMV for more details.

Purse File File that contains purse data, such as its balance, credit and debit security attributes, and the pointer to the cryptographic key used to generate credit certificates.

Record String of bytes that can be handled as a whole by the card and referenced absolutely by a record number or relatively to the current record.

Record Number A sequential number assigned to each record that identifies the record within its EF.

Secret Code A secret code is stored in a secure manner in the card and gives access rights. The user or the application must present a secret code correctly to the card in order to be granted one or more access rights.

Secret Code Descriptor

Each secret code has a descriptor that defines the following information:

- ratification status

- whether or not it has to be entered encrypted

- whether or not it has been initialized

Secure Hash Algorithm (SHA)

A hashing algorithm used in GPK.

© GEMPLUS 2000

220 Terminology

Secure Messaging Process used by GPK to protect administration command transmissions between cards and terminals. This can be done either by encrypting the data that is sent to the card or by sending three bytes of a cryptographic checksum with the command.

Secure Socket Layer (SSL)

A hashing protocol developed by Netscape. It combines the MD5 and SHA hashing algorithms.

Sensitive File DF or EF containing data interpreted by the OS. Such a file comes in five types, each of them being identified by bits b5, b4, b3 in the File Descriptor Byte. Sensitive files include all DFs, DES key files, public key files, secret code files, purse files, transaction manager files and IADF files.

Session Time between two card resets, or between power-up and a power-down.

Session key A temporary cryptographic key that the card uses during sessions involving encryption, decryption operations, cryptographic checksums, secure messaging and so on. Session keys are also called temporary keys.

Short File Identifier (SFI)

This is the five lsb of the file identifier. It is used by certain commands and functions to identify a file.

Signature A numeric cryptogram calculated with a given algorithm and a key.

Signature Key Key used to generate a signature.

Symmetric Algorithm

A symmetric algorithm is a key-based algorithm where the decryption key can be calculated from the encryption key. Often the key is the same. GPK uses the triple DES symmetric algorithm. See "Triple DES".

Symmetric Cryptography

The use of symmetric algorithms to encrypt data.

System File DF or EF containing data interpreted by the card. Such a file comes in five types, each of them being identified by bits b6, b5, b4 in the File Descriptor Byte.

System Key Also referred to as Transport Key, this key is derived from the Mother System Key in the batch card. It is used to com-pute temporary keys for secure messaging when creating DFs.

System keys are either diversified from the mother system key or a constant “TEST KEY”.

Tag, Length, Value (TLV)

A data format, where tag is a number, length is length of data and value is the data itself.

© GEMPLUS 2000

Terminology 221

Temporary Key A cryptographic key that GPK cards use during sessions involving encryption, decryption operations either to generate certificates, cryptographic checksums, secure messaging and so on.

Terminal Transaction Counter (TTC)

A three-byte value that GPK cards use to keep track of transactions executed with each terminal. The terminal must increment the TTC each time it establishes a new payment transaction session.

Transport Secret Code (TSC)

The unique secret code which has to be presented before any physical access to the card memory. It is used during the initialization phase.

Triple DES (3DES) Symmetric and DES key encryption/decryption algorithm based on 16-byte keys. It produces the most secure cryptographic mode in GPK cards.

3DES Key Cryptographic keys that GPK uses for encrypting and decrypting data along with the 3DES algorithm (using 16-byte keys).

Keys come from two sources; they are either retrieved from 3DES key files that are initialized during card personaliza-tion, or they are generated by GPK.

Different types of keys exist and have different purposes for example, payment keys, administration keys.

3DES Key File 3DES key files store the cryptographic keys used in all GPK cryptographic functions. Each 3DES key file can store up to four 3DES keys (16 bytes long).

Unwrap Decrypt a session key that has been encrypted with the RSA algorithm. When the key is encrypted, it is said to be "wrapped" in an envelope.

Verification In public key cryptography, this is a process whereby a certificate for a set of keys is checked to confirm that the keys have been authorized by the certification authority.

© GEMPLUS 2000

Index

Numerics3DES 53

computation of certificates (authenti-cation cryptograms) 55

for key diversification 54key files 21keys 22, 57zero padding 56

3DES_16 x3DES-1 53, 54

AAC secret code reference 2, 8, 45, 49access condition 20access conditions 2, 8, 45

credit 21debit 20, 101, 145freezing 96public key files 27read balance 20

administration commandslist of 85

administration keys 22, 23algorithms

3DES 533DES-1 54DES 183DSA 65, 69MD5 64, 183public key 65RSA 65, 69SHA 63, 183

ANSI padding 1

answer to reset (ATR) 74, 104, 185APDU command format 83append record 17, 87, 128, 164

response 103authentication 22, 55

keys 22, 23authorization registers 46, 49

Bbalance. See purse balanceblank chip phase 201body of files (EFs) 15buffer size 43

Ccancel debit

command descriptionincrementing the TTC 61response 103

cancel debit certificate (CDC) 139cancel debit cryptogram (SDC) 139card authentication 58card balance certificate (CBC) 148card debit certificate (CDC) 139, 146card delivery modes 37card return codes 187card serial number (CSN) 41, 101card signature certificates (CSC) 155card transaction counter (CTC) 150certificates

cancel debit (CDC) 139card balance (CBC) 148card debit (CDC) 139, 146

© GEMPLUS 2000

224 Index

card signature (CSC) 155computation of 55payment 61

certificationpublic keys 66

changing secret codes 117chip serial number 101cipher block chaining (CBC) 55command format 83commands

append record 17, 87, 103, 128,164

cancel debit. See cancel debitcreate file 6, 11, 46, 89, 103create private key file 161credit 22, 57, 142debit 20, 22, 103, 145erase card 162external authenticate 22, 93, 99freeze access conditions 46, 96,

103generate RSA key 75, 163get challenge 93, 99get info 33, 44, 100get response 74, 76, 81, 82,

103InitHashedData 66, 71, 166, 204internal authenticate 22, 58, 103,

105list of administration commands 85list of payment commands 137list of public key commands 159load private key 167, 203, 206PK_Dir 169PK_Int Auth 66, 166, 170, 183,

204PK_OpenEnvelope 66, 68, 82,

172, 183PK_Send 26, 28, 66, 174, 203PK_Sign 66, 175, 183PK_Verify 66, 177, 183PutCryptoData 66, 180read balance 20, 103, 148read binary 107, 202read record 109select file 103, 111select file key 22, 103, 114select purse & key 22, 103, 150set card status 15, 43, 44, 116set options 10, 153set secret code 117sign 22, 57, 153, 155

switch speed 73, 120update binary 56, 59, 103, 123update record 18, 87, 103, 128verify 49, 59, 130write binary 59, 103, 132

communicationprotocol 3, 74speed 73

compatibilityEMV 1, 198ISO 1

computation of cryptographic checksum(CRYCKS) 55create file 6, 11, 46

command description 89response 103

create private key file 161credit

access condition 21cryptogram 142

credit commanddescription 142incrementing the TTC 61key rights (uses) 22to generate temporary credit keys 57

CRYCKS 55cryptograms

cancel debit (SDC) 139credit 142

cryptographic checksum (CRYCKS)computation of 55

cryptographic keys 2cryptography

des-based 53implementation 58key diversification 54public key 3, 63

custom configurations 3custom OS extensions 74cyclic files 17, 87

referencing records 17

Ddata deciphering. See unwrappingdata encryption 59data files 47debit 20

access condition 101, 145maximum free debit 20

debit commanddescription 145

© GEMPLUS 2000

Index 225

incrementing the TTC 61key rights (uses) 22response 103

dedicated files (DFs) 6DF name 10, 112DFSystem 40FDB value 8file descriptor 6

delivery modes 37DES algorithm 183DFSystem file 40diversifying keys 54double reset mechanism 74DSA

algorithm 4, 65, 69keys 183private key elements 31public key elements 29

EEEPROM Size 44EFCard file 40EFIssuer file 42EFKey file 39EFMax session key file 42EFSystem file 43electronic purse 2electronic purse architecture 2elementary files (EFs) 11

3DES key files 21body structure types 15cyclic files 17EFCard 40EFIssuer 42EFKey 39EFMax session key 42EFSystem 43enhanced purse files 21FDB values 13file descriptor 11IADF files 35linear fixed files 16linear variable files 16public key files 24purse files 19secret code files 33structured files 15transaction manager files 32transparent files 15types of 19

EMV compatibility 1, 198

encrypting data 59enhanced purse files

structure 21erase card 162export licenses 4external authenticate command 93, 99

key rights (uses) 22external authentication 58

for selfk and selp&k commands 10,93

using public keys 24

FFDB

DFs 8EFs 13

file body structure 15file control information (FCI) 35file descriptor

DFs 6EFs 11

file hierarchy 5file identifier

DFs 8EFs 14

file level 7file selection

by partial name 11file types 19files

3DES key 21cyclic 17, 87data files 47dedicated (DFs) 6DFSystem 40EFCard 40EFIssuer 42EFKey 39EFMax session key 42EFSystem 43elementary (EFs) 11enhanced purse 21IADF 35, 112linear fixed 16linear variable 16master file (MF) 5, 39number allowed 5public key 24purse 19secret code 2, 33sensitive files 47

© GEMPLUS 2000

226 Index

structured 15transaction manager 32transparent 15

format of commands 83freeze access conditions 46, 96

response 103

GGemplus issuer reference number 41,101

generate RSA key 75, 163generating keys 75get challenge 93, 99get info 33, 44, 100get response 74, 81, 103

to retrieve decrypted data 82to retrieve public portion of generated

keys 76GPK range 1group AC 2, 8, 45, 48

Hhash algorithms 63

IIADF files 35, 112InitHashedData 66, 71, 166, 204initialization phase 201internal authenticate command

description 105key rights (uses) 22response 103

internal authentication 58using private keys 24

IO buffer size 43ISO

compatibility 1padding 1

issuer reference number (EFIssuer) 42,101

issuer reference number (Gemplus) 41,101

issuer serial number (EFIssuer) 42, 101

Kkey

diversification 54files 21, 24generation 75, 163rights 22, 26types 22, 23, 57

key files3DES 21public key 24

keys3DES 22, 57administration 22, 23authentication 22, 23cryptographic 2DSA 183log 22, 23payment 22, 23private 167public 65RSA 163, 183session 2signature 22, 23temporary 3, 57

Llegal restrictions 4length of records 14life cycle 201linear fixed files 16linear variable files 16load private key 167, 203, 206lock byte 44, 101, 116, 162log keys 22, 23

Mmaster file (MF) 5, 39maximum free debit 20MD5 algorithm 64, 183

Ooptions byte 153

DFs 10EFs 14

Ppadding 1

for SHA & MD5 64with zeroes for 3DES 56

payment certificates 61payment commands

list of 137payment keys 22, 23personalization 196

flag 43phase 202recommendations for PK_Crypto ap-

plications 203

© GEMPLUS 2000

Index 227

PK internal authentication 30, 64, 68PK signature 64PK_Dir 169PK_Int Auth 66, 166, 170, 183, 204PK_OpenEnvelope 66, 68, 82, 172,183

PK_Send 26, 28, 66, 174, 203PK_Sign 30, 66, 166, 183, 204

command description 175PK_Verify 66, 177, 183PKCS padding 1pre-personalization phase 202private key elements

DSA 31RSA 30

private keys 167product range 1protocol 74public key

algorithms 65certification 66list of commands 159

public key cryptography 3command processing 160implementation 66

public key elementsDSA 29RSA 28

public key files 24structure 24system record 25

public key signature 69, 175verification 177, 183

public keys 65purse balance 20purse files

enhanced 21structure 19

PutCryptoData 66, 180

Rrange of products 1ratification counter 130read balance

access condition 20command description 148response 103

read binary 107, 202read record 109record length 14referencing records in cyclic files 17

return codes 187RSA

algorithm 65, 69keys 163, 183private key elements 30public key elements 28

Ssecret code

files 2, 33ratification counter 130storage 34

secret codes 45changing 117unblocking 34, 117verifying 130

secure messaging 2security 3select file

command description 111response 103

select file keycommand description 114external authentication requirement

10, 93for secure messaging 48, 59for temporary session keys 150,

167key rights (uses) 22response 103to generate temporary session keys

57select purse & key

command description 150external authentication requirement

10, 93for secure messaging 48, 59for temporary session keys 150key rights (uses) 22response 103to generate temporary session keys

57sensitive files 47session keys 2

also see temporary keysset card status 15, 43, 44, 116set options 10, 153set secret code 117SHA algorithm 63, 183shipment processes 37short file identifier (SFI) 8

© GEMPLUS 2000

228 Index

sign 153command description 155key rights (uses) 22

sign commandto generate temporary signature keys

57signature keys 22, 23speed 73SSL 71, 183status byte

DFs 9EFs 14

structure of file body 15structured files 15switch speed 73, 120system key 39system record 25, 161

Ttemporary keys 3, 57, 148terminal authentication 58terminal transaction counter (TTC) 20,61, 139, 145, 150

transaction manager files 32transparent files 15types of EF 19

Uunblocking secret codes 34, 117unwrapping 68, 81, 172, 183update binary 56

command description 123for encrypting data 59response 103

update record 18, 87command description 128response 103

Vverify 49

command description 130for encrypting data 59

verifying secret codes 130

Wwrite binary

command description 132for encrypting data 59response 103

Zzero padding for 3DES 56

© GEMPLUS 2000

reference manual - error.li · evolution of the document version date principal changes 1.1 oct....

Documents