Multo s Guide

Guide to Generating

GALU MAO-DOC-TEC-009 v2.52

Application Load Units Guide to Generating Application Load Units

GALU MAO-DOC-TEC-009 v2.52

© 2006 MAOSCO Limited. MULTOS is a trademark of MAOSCO Limited.

MAO-DOC-TEC-009 v2.52 © 2006 MAOSCO Limited. ii MULTOS is a trademark of MAOSCO Limited.

Guide to Generating Application Load Units

This Agreement is made between MAOSCO Limited, a company incorporated under the laws of England (registered number 3290642) whose registered office is at St Andrews House, Kelvin Close, The Links, Brichwood, Warrington, WA3 7PB, England (MAOSCO), a subsidiary of Bamboo Holdings, a Cayman Islands company, dba StepNexus (StepNexus) and the Licensee. IT IS AGREED as follows: 1. GRANT AND EXTENT OF LICENCE (1) In consideration of the mutual covenants and undertakings contained in this Agreement and subject to the terms of this Agreement, MAOSCO grants to the Licensee and each of its Affiliates (for so long as it remains an Affiliate of the Licensee), and the Licensee accepts from MAOSCO, a non-exclusive, world-wide licence to use the Licensed Rights and the MULTOS Developer Documents for the sole purpose of developing, using, exploiting, improving and maintaining one or more MULTOS Applications and tools for the development of MULTOS Applications. For the avoidance of doubt, neither the Licensee nor any of its Affiliates shall be entitled, under this Agreement, to use the Licensed Rights and the MULTOS Developer Documents (a) to develop MULTOS Implementations or (b) for any purpose other than as specifically authorised under this subclause. (2) The rights granted by MAOSCO to Affiliates of the Licensee under subclause (1) shall only apply to those Affiliates of the Licensee whose name and principal place of business have been notified in writing, physically or electronically, to MAOSCO (each an "Authorised Affiliate"). The Licensee undertakes to ensure that each Authorised Affiliate is aware of the extent of the Licensee's rights and the Licensee's obligations under this Agreement and shall procure that each Authorised Affiliate observes those rights and obligations. The Licensee shall assume responsibility for any breach by an Authorised Affiliate of the terms of this Agreement and any such breach shall be deemed to be a breach by the Licensee. (3) Other than the Licensed Rights, any Intellectual Property subsisting in any MULTOS Application developed by the Licensee or any of its Affiliates pursuant to subclause (1) shall, as between MAOSCO and the Licensee, vest in the Licensee ("Licensee MULTOS Intellectual Property"). The parties acknowledge that the MULTOS Developer Documents are intended to be an industry standard. The Licensee covenants not to sue, and shall procure that its Affiliates shall not sue, StepNexus, MAOSCO (or any of its sublicensees) with respect to the use, for any purpose, of the Licensee MULTOS Intellectual Property in relation to any MULTOS Application or MULTOS Implementation to the extent that the Licensee MULTOS Intellectual Property is comprised or incorporated in the MULTOS Developer Documents. 2. CRYPTOGRAPHIC CERTIFICATION (1) The Licensee acknowledges that: (a) the MULTOS Card issuer will be required to obtain MULTOS Application load and MULTOS Application delete certificates from MAOSCO and to pay to MAOSCO a fee (to be determined by MAOSCO) in respect of each loading onto, and each deletion from, a MULTOS Card of a MULTOS Application although the MULTOS Applications will not be required to be submitted to MAOSCO; (b) the cryptographic certification process enables the MULTOS Card issuer to control which MULTOS Applications are loaded onto its MULTOS Cards; (c) the cryptographic certificate may also determine whether MULTOS Applications shall be able to call certain cryptographic functions from the relevant MULTOS Implementation; (d) the cryptographic certification process is not a quality control process for MULTOS Applications and that it will remain the MULTOS Card issuer's responsibility to ensure that (i) MULTOS Applications meet its requirements and quality standards and (ii) any territorial specific commercial cryptographic licensing requirements have been fulfilled; (e) legislation in certain jurisdictions restricts the use of some cryptographic functions and, therefore, MULTOS Card issuers and the Licensee may be required to demonstrate to MAOSCO that they have received approval from the appropriate authorities before access to these cryptographic functions will be granted; and (f) the MULTOS Card issuer shall contact the MULTOS security manager (details of whom are published on the MULTOS website on http://www.MULTOS.com), in order to make arrangements for Cryptographic Certification. (2) MAOSCO shall have the right to subcontract the performance of Cryptographic Certification to StepNexus or an Affiliate of StepNexus or any other person. 3. LICENSEE'S UNDERTAKINGS (1) The Licensee undertakes to MAOSCO that it shall: (a) not alter or modify the whole or any part of the MULTOS Developer Documents; and (b) not alter, obscure, remove or interfere with all or any, and shall reproduce on all authorised copies all, of the trade marks, trade names, markings or notices affixed to or contained in any part of the MULTOS Developer Documents and shall mark all authorised copies of the MULTOS Developer Documents with those notices or marks or both as may be required by law; (c) not to disclose all or part of the MULTOS Developer Documents except to the extent expressly permitted by this Agreement. (2) The Licensee agrees that the use of all copies of the MULTOS Developer Documents is subject to the terms of this Agreement. (3) The Licensee shall comply with the Specification Management Procedures. 4. MULTOS DEVELOPER DOCUMENTS AND TECHNICAL ASSISTANCE (1) MAOSCO undertakes to give the Licensee access via website to the MULTOS Developer Documents, with a right to download copies of the MULTOS Developer Documents, for the purposes set out in clause 1(1) as soon as reasonably practicable after MAOSCO has received electronic notification of the Licensee's acceptance of this Agreement. (2) MAOSCO shall comply with the Specification Management Procedures. (3) MAOSCO shall, at the reasonable request of the Licensee from time to time, use its reasonable endeavours to assist the Licensee in dealing with any technical problems which have arisen in the Licensee's use of the MULTOS Developer Documents insofar as MAOSCO is able to do so (including, but not limited to, availability of personnel). Such assistance will be provided by e-mail or website only. (4) If the Licensee requires more assistance than can be provided under clause 4(3), the Licensee should submit a written request for assistance to MAOSCO (by letter, fax or e-mail). The Request should provide details of the nature of the assistance required. If MAOSCO agrees to accept the request MAOSCO's assistance shall be chargeable at its standard rates of charge applicable from time to time. The Licensee shall also reimburse MAOSCO all reasonable expenses incurred by MAOSCO in providing that assistance. Any request for assistance from the Licensee to MAOSCO shall be made only by the designated Licensee's Nominated Representative (or such other person as the Licensee has notified to MAOSCO in accordance with clause 10) to the MULTOS Representative at MAOSCO (details of whom are published on the MULTOS website on http://www.MULTOS.com). 5. PAYMENTS BY LICENSEE TO MAOSCO (1) The Licensee shall pay to MAOSCO, against issue of a valid VAT invoice, the amount of any VAT chargeable on a supply by MAOSCO to the Licensee and, without limiting that payment, each sum payable by the Licensee under the terms of this Agreement is exclusive of VAT (if any) and is accordingly to be construed as a reference to that sum plus any VAT in respect of it. 6. WARRANTY AND INFRINGEMENT (1) Each party warrants to the other that it has all requisite corporate power and authority to enter into this Agreement and is fully capable of performing its obligations under this Agreement on the terms provided for in this Agreement. (2) The Licensee shall promptly inform MAOSCO of any proceedings involving the validity, or any infringement or threatened infringement, of the Licensed Rights and of any unauthorised use of the Licensed Rights or the MULTOS Developer Documents coming to its notice. MAOSCO shall take all action reasonably necessary to prevent the infringement or defend proceedings for revocation or to prevent that unauthorised use, and the Licensee shall, at MAOSCO's request and expense, render all reasonable assistance in connection with that action. (3) Subject to clause 9, the Licensee shall indemnify MAOSCO and its Affiliates from and against all and any damages, losses, costs, expenses and other liabilities awarded against or incurred by MAOSCO and/or any of its Affiliates as a result of or in connection with any claim or action arising out of or relating to any MULTOS Applications developed by or on behalf of the Licensee including, without limitation, any product liability claim ("Claim"), except to the extent that the Claim (if it is a product liability claim) arises out of any specific product feature or functionality expressly mandated by the MULTOS Developer Documents, provided that: (a) MAOSCO promptly notifies the Licensee in writing of any Claim of which it has notice; (b) MAOSCO does not make any admission as to liability or agree to any settlement of or compromise any Claim without the prior written consent of the Licensee which shall not be unreasonably withheld or delayed; and (c) the Licensee may, at its request and expense, conduct all negotiations and (to the extent legally permissible) litigation, and (to the extent legally permissible) settle all litigation, arising from any Claim and MAOSCO shall, at the Licensee's request and expense, give the Licensee all reasonable assistance, at Licensee’s expense, in connection with those negotiations and litigation.

© 2006 MAOSCO Limited. MAO-DOC-TEC-009 v2.52 MULTOS is a trademark of MAOSCO Limited. iii

GALU

(4) NO REPRESENTATION, WARRANTY OR CONDITION, EXPRESS OR IMPLIED, STATUTORY OR OTHERWISE, AS TO CONDITION, QUALITY, PERFORMANCE OR FITNESS FOR PURPOSE IS GIVEN OR ASSUMED BY MAOSCO IN RESPECT OF THE MULTOS DEVELOPER DOCUMENTS AND ALL SUCH REPRESENTATIONS, WARRANTIES AND CONDITIONS ARE EXCLUDED SAVE TO THE EXTENT THAT SUCH EXCLUSION IS PROHIBITED BY LAW. 7. TERMINATION (1) MAOSCO shall have the right, without prejudice to its other rights or remedies, to terminate this Agreement immediately by written notice to the Licensee if the Licensee: (a) shall have failed to pay, in accordance with the terms of this Agreement, any sum due to MAOSCO under the terms of this Agreement and that sum remains unpaid for 30 days after receiving written notice from MAOSCO that it has not been paid; (b) is in material breach of any of its obligations under this Agreement and either that breach is incapable of remedy or the Licensee shall have failed to remedy that breach within 30 days after receiving written notice from MAOSCO requiring it to remedy that breach; (c) challenges the validity of, or MAOSCO's rights in, any of the Licensed Rights provided that compliance by the Licensee of its obligations under clause 6(2) shall not constitute such a challenge; or (d) becomes insolvent or an order is made or a resolution passed for its liquidation, administration, winding-up or dissolution (otherwise than for the purposes of a solvent amalgamation or reconstruction) or an administrative or other receiver, manager, liquidator, administrator, trustee or similar officer is appointed over all or any substantial part of its assets or it enters into or proposes any composition or arrangement with its creditors generally or anything analogous to the foregoing occurs in any applicable jurisdiction. (2) The Licensee shall have the right to terminate this Agreement immediately by written notice to MAOSCO. (3) Any termination of this Agreement shall not affect any accrued rights or liabilities of either party nor shall it affect the coming into force or the continuance in force of any provision of this Agreement which is intended to come into force or continue in force on or after that termination. 8. CONSEQUENCES OF TERMINATION (1) On termination of this Agreement the Licensee shall, subject to subclause (2), immediately cease all use of the Licensed Rights and the MULTOS Developer Documents. (2) Within 30 days after the termination of this Agreement the Licensee shall return to MAOSCO or, at MAOSCO's direction, destroy) all documents and materials (whether in tangible or electronic form) supplied by MAOSCO to the Licensee pursuant to this Agreement and/or which contain or disclose any information contained in or relating to the MULTOS Developer Documents) and all copies then in the possession or under the control of the Licensee and shall use its reasonable endeavours to return to MAOSCO any documents and other materials supplied by the Licensee to a third party. (3) The obligations of the Licensee under clause 1(3) shall survive the termination of this Agreement for whatever reason. 9. LIABILITY (1) The aggregate liability of MAOSCO and its Affiliates to the Licensee under this Agreement, whether arising under any indemnity or from negligence, breach of contract or otherwise, shall not exceed in aggregate £10,000. (2) The aggregate liability of the Licensee to MAOSCO and its Affiliates under this Agreement, whether arising under this indemnity or from negligence, breach of contract or otherwise, shall not exceed in aggregate £10,000. (3) Each party and its Affiliates does not limit its liability for death or personal injury arising from it negligence or that of its employees, agents or sub-contractors. (4) Each party and its Affiliates shall not be liable to the other party for any indirect or consequential loss or damages including, without limitation, loss of business or profits, whether arising under any indemnity or from negligence, breach of contract or otherwise. (5) MAOSCO and its Affiliates shall not be liable to the Licensee for any loss or damages, howsoever arising, in relation to any Cryptographic Technology that is not owned by MAOSCO or StepNexus including, without limitation, ECC, RSA, AES and DES encryption technology. (6) The limitations of liability contained in this clause shall not affect MAOSCO's right to be paid by the Licensee, and the obligations of the Licensee to pay to MAOSCO, the amounts payable to MAOSCO under this Agreement when due. 10. NOTICES Any notice or other document to be served under this Agreement may be delivered or sent by prepaid first class registered airmail or facsimile process to the party to be served as follows: (a) to MAOSCO at St Andrews House, Kelvin Close, The Links, Birchwood, Warrington, WA3 7PB; fax no: +44 (0) 1925 882051; marked for the attention of the Company Secretary, (b) to Licensee at its address and fax number and marked for the attention of the Licensee's Nominated Representative, all identified in the Developer's Licence Agreement electronic registration form, or at any other address or to any other facsimile number or addressee as it may have notified to the other in accordance with this clause. 11. ASSIGNMENT (1) The Licensee shall not assign, sub-license, transfer, mortgage, charge or part with any of its rights, or sub-contract any of its duties or obligations, under this Agreement provided that the Licensee shall be entitled to sub-license (subject to the terms of this Agreement): (a) the Licensed Rights and the MULTOS Developer Documents to a contractor, for such contractor to develop MULTOS Applications for the Licensee under the control of the Licensee and for no other purpose; and (b) the Licensed Rights to customers of the Licensee as end users of the Licensee's MULTOS Applications to the extent that the Licensed Rights subsist in those MULTOS Applications. (2) Nothing in this Agreement shall preclude the Licensee from entering into any collaborative arrangements for the development and/or exploitation of MULTOS Applications with any person who has entered into an agreement with MAOSCO on substantially the same terms as this Agreement. 12. GENERAL (1) A waiver (whether express or implied) by one of the parties of any of the provisions of this Agreement or of any breach of or default by the other party in performing any of those provisions shall not constitute a continuing waiver and that waiver shall not prevent the waiving party from subsequently enforcing any of the provisions of this Agreement not waived or from acting on any subsequent breach of or default by the other party under any of the provisions of this Agreement. (2) Except in relation to the Schedules, any amendment, waiver or variation of this Agreement shall not be binding on the parties unless set out in writing, expressed to amend this Agreement and signed by or on behalf of each of the parties. (3) The invalidity, illegality or unenforceability of any of the provisions of this Agreement shall not affect the validity, legality and enforceability of the remaining provisions of this Agreement. (4) This Agreement and the documents referred to in it contain the whole agreement between the parties relating to the subject matter of this Agreement and supersede all previous agreements between the parties relating to that subject matter. In entering into this Agreement, neither party may rely on any representation, warranty, collateral contract or other assurance (except those set out in this Agreement and the documents referred to in it, and any confidentiality agreement in relation to the MULTOS Developer Documents) made by or on behalf of the other party before the signing of this Agreement and each party waives all rights and remedies which, but for this subclause, might otherwise be available to it in respect of any such representation, warranty, collateral contract or other assurance provided that nothing in this subclause shall limit or exclude any liability for wilful misrepresentation or fraud. (5) This Agreement is governed by and shall be construed in accordance with English law. Each party submits to the exclusive jurisdiction of the English courts for all purposes relating to this Agreement. (6) This Agreement will come into effect when MAOSCO has received electronic notification from the Licensee that the Licensee has accepted the terms of this Agreement 13. INTERPRETATION In this Agreement:

MAO-DOC-TEC-009 v2.52 © 2006 MAOSCO Limited. iv MULTOS is a trademark of MAOSCO Limited.


"Affiliate" means, in relation to any person, any other person that, directly or indirectly through one or more intermediaries, controls, or is controlled by, or is under common control with, such person. The term "control" (including, with its correlative meanings, "controlled by" and "under common control with") means possession, directly or indirectly, of power to direct or cause the direction of management or policies (whether through ownership of securities or partnership or other ownership interests, by contract or otherwise), and provided that if any person: (a) beneficially owns voting securities of another person conferring more than 50 per cent. of the votes eligible to be cast in the election of directors or any similar matter; or (b) has the right (by contract or otherwise) to appoint or remove directors (or members of a governing body having functions similar to a board of directors) representing more than 50 per cent. of the votes exercisable by all the directors (or persons having similar functions) of another person, then the first person is conclusively deemed to control the other person for the purposes of this definition. "Cryptographic Certification" means the process described in clause 2(1). "Cryptographic Technology" means those mechanisms that are functionally designed (a) to preserve the confidentiality, authenticity or integrity of digitally stored and/or transmitted data or (b) to authenticate information as part of a security service through the use of algorithms that involve secret parameters, commonly known as keys. "IC Card" means an integrated circuit card. "Intellectual Property" means patents, patent applications, patented and unpatented inventions, design rights, copyrights (including, without limitation, rights in computer software), topography rights, know-how and trade secret rights, and all other intellectual property rights and the rights or forms of protection of a similar nature or having equivalent or similar effect to any of these rights which may subsist anywhere in the world (whether or not any of these rights is registered and including, without limitation, applications for registration of, and rights to apply for, any such rights). "Licensed Rights" means all Intellectual Property in and to the MULTOS Developer Documents. "MULTOS Application" means a program written to run, in a compiled, interpretative, executable or any other form, on or interface with, any MULTOS Implementation or which processes data to be used on or in conjunction with any MULTOS Implementation. "MULTOS Card" means an IC Card which incorporates a MULTOS Implementation. "MULTOS Developer Documents" means the documents listed in Schedule 1, as amended by MAOSCO from time to time. "MULTOS Implementation" means an operating system (including the silicon platform) which (a) supports multiple applications, (b) conforms, or is intended to conform, to the MULTOS Specification and (c) uses Cryptographic Certification. "MULTOS Specification" means the specifications, licensed by MAOSCO, defining the functional and security requirements and the application programming interface for multi-application architectures, as amended by MAOSCO from time to time. "StepNexus" means Bamboo Holdings, a Cayman Islands company, dba StepNexus. "Specification Management Procedures" means the procedures set out in Schedule 2 or any other procedures which MAOSCO may notify the Licensee in writing from time to time. "Update" means all and any updates or new releases or new versions of the MULTOS Developer Documents. "VAT" means any value added tax chargeable by virtue of any enactment in a territory introduced by reason of the Sixth Council Directive 77/388/EC or its predecessors or similar subsequent legislation or any similar tax. SCHEDULE 1 MULTOS Developer Documents MULTOS Developers Guide (MDG) MULTOS Developers Reference Manual (MDRM) Guide to Loading and Deleting MULTOS Applications (GLDA) Guide to Generating Application Load Units (GALU) MULTOS Implementation Report (MIR) Developer Card: User Guidelines (DCUG) MULTOS Standard C API (CAPI) Plus other documents made available from time to time by MAOSCO. SCHEDULE 2 Specification Management Procedures 1. MAOSCO shall, as soon as practicable after they become available, make available to the Licensee all and any Updates which are issued generally by MAOSCO to other persons who have been licensed by MAOSCO to use the MULTOS Developer Documents. 2. The Licensee shall ensure that within 30 days after access to any Updates is permitted by MAOSCO to the Licensee, all documents or materials (whether in tangible or electronic form) supplied by MAOSCO pursuant to this Agreement which contain or reference that part of the MULTOS Developer Documents which has been substituted or amended by any Update supplied by MAOSCO are returned to MAOSCO (or, at MAOSCO's direction, destroyed). 3. The details of the person responsible on behalf of MAOSCO for the Specification Management Procedures as set out in this Schedule are published on the MULTOS website on http://www.MULTOS.com.

© 2006 MAOSCO Limited. MAO-DOC-TEC-009 v2.52 MULTOS is a trademark of MAOSCO Limited. v

GALU

Copyright

© Copyright 1999 – 2006 MAOSCO Limited. This document contains confidential and proprietary information. No part of this document may be reproduced, published or disclosed in whole or part, by any means: mechanical, electronic, photocopying, recording or otherwise without the prior written permission of MAOSCO Limited.

Trademarks

MULTOS is a trademark of MAOSCO Limited. All other trademarks, trade names or company names referenced herein are used for identification only and are the property of their respective owners

Published by

MAOSCO Limited St. Andrews House Kelvin Close The Links Birchwood WARRINGTON Cheshire WA3 7PB United Kingdom .

General Enquiries

Email: [email protected] Tel: +44 (0) 1925 882 050 Fax: +44 (0) 1925 882 051 Web: http://www.multos.com

Technical Enquiries

Email: [email protected] Web: http://www.multos.com

Document References

All references to other available documentation is followed by the document acronym in square [ ] brackets. Details of the content of these documents can be found in the MULTOS Guide to Documentation, and the latest versions are always available from the MULTOS web site (http://www.multos.com).

http://www.multos.com/

http://www.multostechnet.com/

http://www.multos.com/

MAO-DOC-TEC-009 v2.52 © 2006 MAOSCO Limited. vi MULTOS is a trademark of MAOSCO Limited.


Data References

All references to MULTOS data can be cross-referenced to the MULTOS Data Dictionary.

Version Information

1.00 Nov 1998 First Issue for release 1.10 Jan 1999 Corrections to initial document 1.20 May 1999 Corrections to document and new material 2.00 Oct 1999 Major review. Examples and version differences added. 2.10 Oct 1999 Differences between v3 and v4 MULTOS certificates

added Anomaly of Keycorp v1K MULTOS certificate added. Examples for v3 and v4 certificate retrieval added.

2.20 Nov 1999 Important Note about Generating the code hash for MULTOS v4 applications with encrypted code segment

2.30 Jan 2000 Various review comment added Error in Types of Application Load Units diagram. The Application Signature is created for the enciphered Application Unit, and does not include the KTU

2.40 Jan 2000 Error in diagram and error in examples, final code component corrected. Examples now include sample ALU/ALC/ADCs.

2.50 Sept 2000 Added worked example for 3114 2.51 Dec 2002 Clarified application signature generation in section 2.4 2.52 Sep 2006 Reformatted. Removed MULTOS 3 related sections and

MEL RSA application code.

© 2006 MAOSCO Limited. MAO-DOC-TEC-009 v2.52 MULTOS is a trademark of MAOSCO Limited. vii

GALU

Contents

Introduction ......................................................................................................................................1 Overview .......................................................................................................................................1 Loading Applications .....................................................................................................................3 Types of Application Load Units .....................................................................................................4

Unprotected ALU .......................................................................................................................4 Protected ALU............................................................................................................................4 U

Confidential ALU........................................................................................................................5 Additional Notes ........................................................................................................................5

ALU Generation Overview .................................................................................................................6 Additional Notes............................................................................................................................7 Public Keys ....................................................................................................................................8

MCD Public Key .........................................................................................................................8 Recovery ....................................................................................................................................9 Deciphering the Ciphertext.......................................................................................................11 Verification ..............................................................................................................................12 MULTOS Transport Key Certifying Keys.....................................................................................13 Application Provider Keys .........................................................................................................13

Summary .....................................................................................................................................14 Additional Information .............................................................................................................14

Generating Application Load Units ..................................................................................................15 Structure of Application Load Units..............................................................................................15

MCD_Number..........................................................................................................................16 Code Record ............................................................................................................................16 Data Record .............................................................................................................................16 DIR Record ...............................................................................................................................16 FCI Record ...............................................................................................................................16 Application Signature ...............................................................................................................16 KTU .........................................................................................................................................17

Structure of the Application Unit..................................................................................................17 Generation of the Key Transformation Unit ..................................................................................18

Overview..................................................................................................................................18 Procedure ................................................................................................................................18 Plaintext KTU Overview ............................................................................................................19 Ciphertext Application Unit ......................................................................................................21 Ciphertext KTU ........................................................................................................................21

Generation of the Application Signature ......................................................................................22 Procedure ................................................................................................................................22 Calculating the Hash Digest......................................................................................................23 Hashing Algorithm ...................................................................................................................25 Application Provider Private Key ...............................................................................................27 Application Signature ...............................................................................................................27

MULTOS V4 Confidential ALU .........................................................................................................28 Plaintext Application Load Unit ....................................................................................................28 Plaintext Application Unit.............................................................................................................29

Combined Application Unit ......................................................................................................30 Enciphering Application Units ......................................................................................................30

The encryption process.............................................................................................................31

MAO-DOC-TEC-009 v2.52 © 2006 MAOSCO Limited. viii MULTOS is a trademark of MAOSCO Limited.


Retrieval/Authentication of MULTOS Card Public Key ...................................................................31 Recovering the Public Key.........................................................................................................33 Interpretation of decrypted certificate ciphertext.......................................................................34 Authenticating the certificate ...................................................................................................34

Generation of Ciphertext KTU......................................................................................................37 Generation of the Application Signature ......................................................................................39

The Calculation ........................................................................................................................40 Plaintext Application Signature .................................................................................................43 Application Provider’s Private Key .............................................................................................43 Application Providers Public Modulus and Exponent .................................................................44 Enciphered Application Signature .............................................................................................44

Creating the Confidential Application Load Unit...........................................................................45 Application Load Unit...............................................................................................................46 Application Load Certificate .....................................................................................................46 Application Delete Certificate ...................................................................................................47

© 2006 MAOSCO Limited. MAO-DOC-TEC-009 v2.52 MULTOS is a trademark of MAOSCO Limited. 1

GALU

Introduction This document has been aimed at MULTOS v4 developers, but the differences between v4 and MULTOS v3 have been noted where relevant.

Overview This section gives an overview of how Application Load Units are used within the MULTOS Scheme. To understand this, the whole loading and deleting process must be considered. The following diagram shows the MULTOS Scheme with respect to the loading of applications.

CardIssuer

Application Provider

Application Load Facility

Certification Authority

Application Load Unit Generator

Application Provider Private Key

Application Provider Public Key

MEL Application

Application Load Unit

MSM Controls Data

MULTOS Card Public Keys

Customer Database for personalisation

ApplicationLoadCertificate

Application Header

MELMELMEL

MEL

MEL

MEL

MEL

MEL

The MEL Application itself and the Application Provider’s Private Key are generated by the Application Provider and must be sent to the Application Load Unit Generator to build the Application Load Units. The Application Provider’s Private Key is required to generate a Protected or Confidential Application Load Unit. Protected and Confidential Application Load Units are described in detail later in this document.

The Application Header for the Application along with the Application Provider’s Public key is sent to the Card Issuer who must send these to the MULTOS CA as part of the Application Registration process. The MULTOS CA will use this information when generating the Application Load and Delete Certificates, which provide the main mechanism by which an application is authenticated during the loading process. The Application Header contains a brief outline of the application’s main characteristics. The Application ID, Application Code Hash, Code Size and Data Size are the most important parts of this header information. Other characteristics specified in the Application Header relate to the type of application (standard or shell) along with whether the application is able to edit

MAO-DOC-TEC-009 v2.52 © 2006 MAOSCO Limited. 2 MULTOS is a trademark of MAOSCO Limited.


the ATR historical characters, the session data size, DIR record size and the size of File Control Information supplied.

The MCD Public Key and any Personalisation Data which is to be included in the Application Load Unit are sent to the Application Load Unit Generator. The MCD Public Key is required for the generation of Confidential ALU, which must be generated for a specific Target MULTOS Card. A Confidential ALU is one that has been enciphered and can only be read by the Target MULTOS Card that contains the matching private key.

The Application Load Unit is essentially the MEL Application, supplied by the Application Provider, plus any personalisation data, provided by the Card Issuer. These can be protected with signatures and encryption if necessary. The Application Provider’s Private Key is used to sign a Hash Digest of the application. The MCD Public Key is used to provide the security in Confidential Application Load Units.

Although not directly connected with the actual generation of the Application Load Unit, the Application Load Certificate is closely related to the Application Load Unit and is required to load an application onto a MULTOS Card. The Application Load Certificate, ALC, is a certified copy of the Application Provider’s Public Key along with the Application Header. The ALC is signed using the MULTOS CA’s Private Key Certifying Key (PKCK) and all MULTOS Cards of a specific implementation are able to verify the authenticity of this certificate.

Example The various entities described - Application Developer, Application Provider, Card Issuer, Application Load Unit Generator and Application Load Facility - may be separate, but in practice some of them will be carried out by the same entity. An example would be a bank, which operates as a Card Issuer. It subcontracts Application Development for a specific application to a software house. A separate card bureau performs the Application Load Unit Generation and the Application Loading. The bank retains the Application Provider function for the application so that it can generate confidential Application Load Units, and so retain control of the encryption process used in the generation. This bank wishes to issue a new card product using MULTOS with two applications on the card. One is an electronic purse supplied by an established payment organisation and the other is an application that the bank has contracted a third party software house to write. A purse product has secret keys stored within it and these must be protected. In the case of this application the bank does not control the Application Provider key pair as the payment organisation has this responsibility on behalf of the scheme and assumes responsibility for the protection of the secret keys contained within the application. The purse supplier, i.e. the payment organisation, acts as the Application Provider and generates the Application Load Units which are enciphered to protect the secret keys and to provide integrity throughout the process before they are loaded on the bank’s cards. Each of the Application Load Units will be specific to a single MULTOS Card, since parts of the unit will be encrypted with the cards public key.


GALU

The application written by the third party company is supplied to the bank in plaintext format. So the MEL application code is itself not protected from inspection by the bank, or anyone else. In the case of this application the bank does generate the required Application Provider keys and produces the Application Load Units themselves. The key point to note here is that the Application Provider keys may be generated by either the Application Developer, or the Card Issuer; the decision depends upon the degree of security required or mandated by each of the parties.

Loading Applications This section is a brief overview of the process involved in loading applications onto a MULTOS Card. This process is described in detail in a separate document, Guide to Loading and Deleting Applications.

Load/Delete Certificates


MULTOS Smartcard

MCD Private Key

MEL

The Application Load Unit (ALU) provides the application code, data, directory file entry (DIR), and File Control Information (FCI) for the application. This may be Unprotected, Protected or Confidential depending upon the security required during the loading process. For example, within a secure environment an Unprotected Application Load Unit could be used, but in many cases a Protected or Confidential ALU will be required to provide security for the application’s code or data.

The Application Load Certificate (ALC) provides the ability for the MULTOS Card to verify that the Application to be loaded is valid and that the Card Issuer has authorised the loading of the Application.

The MULTOS Card itself must have been enabled for the Card Issuer by loading the MULTOS card enablement data, called MULTOS Security Manager (MSM) Controls Data. It is not possible to load any application until the card has been enabled. When a card is enabled it will be given its MULTOS Carrier Device (MCD) Private and Public Keys, which are used during the Application Load process to decipher any enciphered portions of the ALU.



The load process involves sending the ALU and ALC to the MULTOS Card. Beyond matching up an ALC, ALU and a MULTOS Card there is little processing required here. Any security must already be present within the ALU and ALC.

Types of Application Load Units There are three types of Application Load Unit allowable within the MULTOS Scheme.

Unprotected ALU Protected ALU Confidential ALU

KTU

Application

Application SignatureKey Transformation Unit

In Confidential ALUs theApplication is either fullyor partially enciphered toprotect secret data.

In Confidential ALUs theApplication Signature is createdfor the enciphered ApplicationUnit. It does not include the KTU

An Application Load Unit consists of three main components:

• Application - the application itself, which is divided into four smaller components o Code Record o Data Record o DIR Record o FCI Record

• Application Signature - enables the ALU to be protected against changes. • Key Transformation Unit - enables the ALU to be enciphered.

The types are described below in order of generation of the various security protections, but since the creation of the Application Signature is always the last step (if it happens), the details are described, in later sections, in a slightly different order.

Unprotected ALU An Unprotected ALU is a MEL application packaged into the ALU Structure. The MEL application may be produced using a compiler or assembler. It contains no Application Signature and therefore no protection against tampering or corruption. There is also no Key Transformation Unit so the Application Load Unit is plaintext, not enciphered, and therefore can be easily read. The generation of an Unprotected Application Load Unit is simply a case of creating the correct file structure.

Protected ALU A Protected ALU is an Unprotected ALU that has a digital signature, the Application Signature. The Application Signature is created using the Application Provider’s Private Key and therefore can only be generated by the Application Provider. This Application Signature allows any tampering or corruption of the Application Load Unit to be detected by a MULTOS Card. The Application Load Unit is not enciphered, however, and so can be easily read.


GALU

Appending the Application Signature of the application to an Unprotected ALU generates a Protected Application Load Unit.

Confidential ALU A Confidential ALU has one or more sections enciphered. The details of this encryption, including the encryption keys used, are stored in a Key Transformation Unit (KTU). The Key Transformation Unit is enciphered using the MCD Public Key of the Target MULTOS Card. The Enciphered Application Unit is then signed generating an Application Signature.

Additional Notes Each of the different ALU types are stored using the same file format, the difference between them lies in the presence of the Application Signature and the Key Transformation Unit for Protected and Confidential ALU. In Confidential ALU the data is just stored in enciphered form in the ALU. Example An issuer wishes to provide a card that has several applications loaded on it. One application will always be present on every card and is loaded within a secure environment before cards are first issued. Typically this would be performed at a card-processing bureau. Since enciphering the application would slow down the loading process, the application is not actually enciphered but relies on the secure loading environment. It is the bureau’s operating procedures and security that now protects the ALU. One application contains no secret data, but must be loaded within an insecure environment. For example, the application may be a loyalty application that is loaded within a supermarket. Although the supermarket is manned, it is not a secure environment. Since the Loyalty application contains no sensitive or secret data Protected ALU are generated. This will ensure that the application is not tampered with or corrupted. The ALU themselves can be easily read, but since they contain no secret information this is not important. Two applications must be secure since they contain secret information and the customer may choose to dynamically load either onto the card. Confidential ALU are generated for these applications, which enables the customer to load one application within an insecure environment. Also, since the security is present within the ALU it is not possible for the customer or an eavesdropper to read or tamper with the application during the loading process.



ALU Generation Overview The following diagram shows an overview of the process of generating an Application Load Unit.


EncipheredKTU

ApplicationSignature

Application

Application ProvidersPrivate Key

MCD Public Key

Customisation Data

Application LoadUnit Generator

MEL

MEL

MEL

MEL

MEL

MELMELMEL

SIG

The Application itself consists of the application code, data, directory file entry and file control Information. The Application Provider will supply this. The Application Data may contain initialisation values for the application, but will not usually contain any data that is specific to a particular customer.

Optional. The Customisation Data consists of data that is used to personalise an Application Load Unit for a particular consumer. In this case there must be one Application Load Unit generated for each target consumer / Target MULTOS card. The Customisation Data may be anything from a set of encryption keys specific to the MULTOS Card, or information about an actual consumer such as account details, or the consumer’s name. There is no requirement for personalisation to occur during the ALU Generation stage, though it does allow secure loading of such information.

The Application Provider’s Private Key is part of an RSA Public/Private Key set. The Private Key is used during the generation of a Protected or Confidential ALU and therefore gives complete control to the Application Provider of who can read the final ALU. The Private Key is used to generate the Application Signature. If there is no Application Signature than this key is not required. The presence of an Application Signature ensures that the ALU is protected against changes.


GALU

The MCD (MULTOS Carrier Device – smartcard) Public Key is required to generate Confidential Application Load Units. For an Application Load Unit to remain confidential it is important that only the Target MULTOS Card is able to read the ALU. This is achieved by enciphering the ALU and then enciphering the information required when deciphering the ALU with the Target MULTOS Card’s Public Key. The information required to decipher the ALU is held in a Key Transformation Unit attached to the ALU. This KTU is enciphered and only the Target MULTOS Card has the corresponding private key with which to decipher the KTU and hence decipher the ALU.

The Application Load Unit generated may be either generic (plaintext or protected) and be usable for a large number of cards, or it may be specific to a single MULTOS Card, i.e. a Confidential ALU. If the ALU is specific to a single MULTOS Card then there must be one ALU per Target Card. There is provision within the recommended file formats to store either a single ALU or many ALU.

Additional Notes The MCD Public Key (the public key of the card) is available in a certificate returned by the MULTOS CA with the enablement data or by the card itself in response to an Open MEL command. This key must be extracted from the certificate and the corresponding Transport Key Certifying Key (TKCK) Public Key is required to do this. Please contact the MULTOS KMA to order this key. Example An Issuer requires Application Load Units (ALU) to be generated for use on the issuer’s web site. Cardholders must be able to download, via the Internet, the applications that they want on their cards. If the application has sensitive information stored within it then confidential ALU must be used. The Issuer uses a bureau to generate the Application Load Units. To generate the ALU required, the Bureau must be given the Application’s compiled code and data itself, the Application Providers Private key, the MCD Public Key of each Target MULTOS Card and any customised data for each of the ALU. In order for the Consumers to be able to use these ALU there must also be an appropriate ALC available and the consumer must have software capable of receiving the files over the Internet (e.g. a browser). A loader and card reader will also be necessary to load the ALU and Application Load Certificate (ALC) onto the card.



Public Keys The security of Protected and Confidential Application Load Units and the integrity of the Application Loading and Deletion processes depend upon the management and handling of keys. Like any other system based upon cryptography, the security ultimately relies upon the keys and this section explains the importance of the keys and how each is used. For the MULTOS Developer Cards all public developer keys are given in the Developer Card: User Guidelines (DCUG) document. The following diagram shows an overview of the keys involved with the process of application loading, deleting and application load units.

CardIssuer

Application Provider

Application Load Facility

Certification Authority

Application Load Unit Generator

Application Provider Private Key

Application Provider Public Key

MEL Application


MSM Controls Data

MULTOS Card Public Keys

Customer Database for personalisation

ApplicationLoadCertificate

Application Header

MELMELMEL

MEL

MEL

MEL

MEL

MEL

The actual sizes of these keys are version or even implementation specific.

MCD Public Key The MCD Public Key is required for the generation of Confidential Application Load Units. The Key Transformation Unit is enciphered using the MCD Public key of the Target card and only this specific Target MULTOS Card is able to decipher the KTU and therefore decipher any encrypted portions of the Application Load Unit (e.g. code and/or data). The security of the Confidential Application Load Unit therefore relies upon the authenticity of the MCD Public Key. For this reason the MULTOS CA signs MCD Public Keys using the MULTOS CA’s Private Transport Key Certifying Key and the MCD Public Key is therefore made available in certified format. For example, it is likely that the Application Load Unit Generator will not receive MCD Public Keys in plain text format. The MCD Public Keys are distributed as Certified Public Keys and these must be


GALU

deciphered to validate their authenticity so that the Application Provider knows that they correspond to legitimate keys that came from the MULTOS CA. The MULTOS CA will supply an Issuer with a copy of all MULTOS Public Key Certificates generated for their cards. When an Issuer requests Enablement Data for a new MULTOS Card the CA will return, as part of the Enablement Data, a copy of all the specific MULTOS Public Key Certificates for all the MULTOS cards. It is the responsibility of the Issuer to retain this information and pass the certificates onto any other entities that may need them. The Certificates are then deciphered using the MULTOS CA Public Transport Key Certifying Key (tkck_pk) to find out the public key for the card (multos_pk_certificate).

MSM Controls Data

MULTOS CA PublicKey Certifying Key(Transport)

TKCK

MCD Public Key

MULTOS Card

MULTOS Public KeyCertificate

MULTOS Public KeyCertificates

D

A MULTOS Card will return its Public Key Certificate in response to an Open MEL Application command. This may be more useful for dynamically loaded applications where the card is available to respond. For cases where ALU are being generated en mass then this method is unlikely to be practical and the list of public keys returned by the MULTOS CA with a set on enabled cards can be used instead, to pre-generate the ALU. Note that the MULTOS KMA keeps a copy of every card specific public key every generated, and hence an Issuer can always request a copy from the CA after the event if they have lost their copy.

Recovery The Messages corresponds to the entire Public Key Certificate and will consist of two portions. The most significant, left hand side, bytes will be plaintext, whilst the least significant bytes will be enciphered. There are always at least the Public Key Length (pkl) bytes in a message.

Certificate CiphertextPlain Text Header

Certificate Body

pkl

Certificate Length

Plaintext Length

Plaintext Length = Certificate Length - pkl



Key Header Format The following diagram shows the structure for the Key Header for the MULTOS Public Key Certificate.

Key Type

Key Identifier

Certification Method ID

Hash Method ID

Public Key Length

Certifying Key Length

Algorithm ID

Public Exponent Length

Public Exponent

MCD Issuer Product ID

MCD Issuer ID

Set MSM Controls Data Date

MCD Number

1

8

2

2

2

2

1

24

1

4

1

8

Name Size

• Key Type: This is used to indicate the type of key contained within this certified public key. Different key types have different data fields included within the certificate.

• Key Identifier: An eight byte identifier of a cryptographic key. • Certification Method ID: This is a single byte value which specifies the way in which the

public key has been certified. In practise this will correspond to the key certifying key which has been used.

• Hash Method ID: This is a two byte value which specifies the hashing algorithm and hash modulus which is used for both the certification of keys and also for the checking of applications during loading.

• Public Key Length: This is a two byte field which holds the length of the public key being certified.

• Certifying Key Length: This is a two byte field which holds the length of the key certifying key used to produce the public key certificate.

• Algorithm ID: This is a single byte field that identifies the algorithm which the certified key is intended to be used with.

• Public Exponent Length: This is a double byte field that specifies the length of the Public Exponent.

• Public Exponent: This is a four byte field that holds the Public Exponent. The Public Exponent should be aligned in the most significant bytes of this field.

• MCD Issuer Product ID: This is a single byte field which specifies the Product ID assigned to the MULTOS Card for which this key is the Public Key.

• MCD Issuer ID: This is a four byte field which specifies the Issuer ID of the Card Issuer who issued the MULTOS Card.

• Set MSM Controls Data Date: This is a single byte field which specifies the MSM Controls Data Date for the MULTOS Card.

• MCD Number: This specifies the eight byte MCD Number for the MULTOS Card. Note that MULTOS version 4 also has the top bytes of the public key at the end of the header, if the 16 byte hash modulus + the public key is greater that the TKCK modulus length.


GALU

Deciphering the Ciphertext The first step is to decipher the enciphered portion of the certificate; this is called the Ciphertext Signature. Once the Ciphertext Signature has been deciphered the resulting plaintext will comprise of a Digest and the Recovered Key. Depending upon the length of the actual key, and the version of MULTOS, the Recovered Key may contain padding, or may only contain the least significant bytes of the key with the most significant bytes being held in the Plaintext portion of the original certificate.

DIGEST’ Recovered Key

Recovered Key

Recovered Key

Plain Text Header

Plain Text Header

A short public key is able to be completely held within the Recovered Key

A longer public key will have a portion held within the Plain Text Header.

The Public Key to be certified may have to be either padded or split in order to generate the plaintext to be enciphered in the final certificate. A value called the Message Block Length is the maximum size of public key which can fit into the enciphered portion of the certificate. The Message Block Length, mbl, is equal to the size of the Certifying Public Key minus the size of the Digest. The size of the Digest is usually represent by the value Hash Chain Length, abbreviated to hcl in the above diagram. The size of the key certifying key is represented by the term Public Key Length, pkl in the above diagram.

pkl

mblhcl

Message Block Length = Public Key Length - Hash Chain Length

Hash Chain Length

Public Key Length

Message Block Length



The following diagram shows the cases where the public key is longer and shorter than the Message Block Length.

pk_padding

PK_Digest PK_Digest

(pk_top)

pk_redundancy pk_redundancy

PublicKey

PublicKey

pk_bottompk_bottom

Key

Cer

tifyi

ng K

ey

Key

Cer

tifyi

ng K

ey

mbl mbl

16 bytes 16 bytes

hcl hcl

Long Public Keys must be split Short Public Keys must be padded

If the Public Key plus pk_redundancy is larger than the Message Block Length, mbl, then a portion of the Public Key, denoted pk_top in the diagram, will remain as plaintext within the final public key certificate. If the Public Key plus pk_redundancy is smaller than the message block length then it must be padded to equal the size of the message block length. This padding is denoted as pk_padding in the diagram. If the Public Key plus pk_redundancy is equal to the message block length then there will be no pk_top or pk_padding bytes within the certificate. The portion of the Public Key contained within the enciphered certificate is denoted as pk_bottom. In many cases this will be equivalent to the Public Key, but the term pk_bottom is used so that the text remains as generic as possible. The signature portion of the certificate is divided into two portions. One is the Hash Digest of the whole Plaintext Certificate. The second is the enciphered Public Key plus Padding, or at least the portion of the Public Key which was able to fit into the signature for enciphering. At this stage the full plaintext certificate may be constructed by appending the Recovered Key (pk_bottom) to the plaintext in the header of the original certificate (pk_top). However, it is strongly recommended that the Digest is calculated and compared to the one recovered from the certificate in order to validate the authenticity of the recovered key.

Verification The Plaintext portion of the certificate should be padded to be a multiple of the Hash Block Length, and then a Hash Digest calculated using the Asymmetrical Hashing Algorithm. This forms the first iteration of the Hash Digest. The recovered portion of the public key (pk_bottom) is then hashed using the result of the first hash iteration as the Initial Vector.


GALU

The result of this hash is then the final digest, which must match the Digest recovered from the certificate. Note that on MULTOS v3: Only the first hash is performed on version 3 cards and the result is the digest. See the version examples for more details. The most significant bytes of the deciphered signature, Hash Block Length bytes, contain the certificate’s digest. This must match the digest generated from the recovered key in order to confirm that the public key is authentic. The example sections give details of how the public key was recovered for MULTOS development cards

MULTOS Transport Key Certifying Keys The MULTOS Transport Key Certifying Keys are a pair of asymmetric keys, one public and one private. The MULTOS KMA will make the public key available upon request and this is used to recover and verify any MULTOS card certified public keys (multos_pk_certificate) produced by the MULTOS CA. The Private Transport Key Certifying Key remains secret and is known only to the MULTOS CA. The security of a Confidential ALU relies ultimately upon the authenticity of the MULTOS Transport Key Certifying Key used, since the verification of the MCD Public Key relies on the use of the MULTOS CA Public Key Certifying Key. It is important to ensure that any MULTOS KMA Key Certifying Keys used are received by a trusted route and verified to be authentic. The MULTOS KMA manages the supply of the MULTOS CA’s Public Transport Key Certifying Key to Application Providers. The MULTOS KMA may have different Key Certifying Keys since keys may be replaced over time and new keys may be generated for new MULTOS implementations. The MULTOS Data Dictionary has a data item certification_method_id, which lists the id of the key used for all MULTOS implementations. Note: Different cetification_method_id and keys are used for developer and live cards.

Application Provider Keys The Application Provider must generate an asymmetric key pair if protected or confidential ALU are to be used. The private key is used for the generation of the Application Signature and the protection of the application relies on the security of this key. The public key is ultimately passed to the MULTOS Card via the MULTOS CA who embeds it securely in the Application Load Certificate where it is used to verify the application has not been corrupted or tampered with. Note: The protection of the application does not include confidential information. The confidentiality of the application and its data relies upon the MCD Public Key as described earlier in this section. The Application Provider Keys are used to protect their application from corruption and tampering. The Application Providers Private Key is used to generate an Application Signature and is required for all Protected and Confidential Application Load Units. The Application Provider’s Private Key will still exist for an Unprotected ALU, but will not be used and therefore can be left blank. The Application Provider’s Private Key could be generated by either the Application Provider or the Issuer, depending upon who requires a secure ALU. The key must be passed on to the Application Load Unit Generator, who therefore must be a trusted party. It is common for the entity generating the Application Load Unit to be the same as the entity that generated the Application Provider’s Key.



Summary The MCD Public Key may be recovered from the MULTOS Public Key Certificate using the MULTOS CA’s Key Certifying Key The security of a Confidential Application Load Unit ultimately depends upon the authenticity of the MCD Public Key whose authenticity depends upon the MULTOS CA’s Public Transport Key Certifying key. It is important that all keys are trusted. The Application Provider can also generate their own keys for signing applications.

Additional Information There are additional details of the structure for public key certificates in the document File Interface Formats [FIF].


GALU

Generating Application Load Units The process of generating an application load unit is summarised in the following diagram.

Encipher areasof ApplicationUnit usingDES or 3DES

Protected ALU

Unprotected ALU

Card SpecificData

Application

Confidential ALU

MEL

MEL

MEL

MEL

MEL

MEL

Generate KTU

Encipher KTUwith MCD Public KEY

GenerateApplication Hashwith MCD Hash Modulus Key

Sign Hashwith ApplicationProviders PrivateKey

For simplicity an Unprotected Application Load Unit is regarded as being essentially the same as an Application. Technically an Unprotected ALU has a complete copy of the Code, Data, DIR Record and FCI Record defined within a fixed structure whereas an Application could be held in any proprietary structure without either a DIR Record or FCI Record. For example, an application may be the output from a toolkit.

Structure of Application Load Units This section describes the structure of an Application Load Unit. All types of Application Load Unit use the same structure although certain components may be empty. For example, in Unprotected ALUs the Application Signature and Key Transformation Unit components will be empty and have a length of zero.

Mcd_Number

record lengthrecord data

Code RecordData RecordDIR RecordFCI Record

Application Signature

KTU

Components

The Application Load Unit contains the complete application: Code, Data, DIR File entry and File Control Information. The details of the various components are shown in the diagram above. An Application Load Certificate is also required to load an application onto a MULTOS Card, to authenticate the load process. This is stored separately from the actual application normally. Note: The record length fields in all of the files are stored in a bigendian manner, i.e. have their most significant byte first, and followed by the least significant byte. Unless stated otherwise, this applies to all two byte length fields within this document.



If a record is absent the record length is set to zero and the record data is empty.

MCD Number An MCD Number is the unique identifier of a specific MULTOS Card. The MCD Number field of an ALU allows the ALU to be locked to only one card. The ALU may contain personalisation data (data specific to a certain user) or the public key of the specific MULTOS card may have been used to encipher portions of the application code and data and create the KTU (confidential ALU). For Unprotected and Protected ALU, where the load unit will not be limited to one card, the MCD Number should be set to eight zeros.

Code Record The Code Record contains the MEL Code of the Application. The length of the code is held in the first two bytes followed by the code itself. The code will normally have been produced using either an assembler or a compiler.

Data Record The application data component holds a snapshot of the Static Segment that the application has available when first loaded. Please see the section on memory in the Application Abstract Machine chapter of the MULTOS Developers Guide for more details on memory segments.

DIR Record The DIR Record for a file contains information about the name of the application when loaded on the card. At application load time the content of the DIR record is entered into the smart card DIR File by MULTOS. The DIR Record portion of the ALU is formatted using the first two bytes to hold the length, followed by the DIR Record itself. Each MULTOS Implementation will have a maximum size for a DIR Record and it should be formatted according to the ISO 7816-5 standard.

FCI Record The File Control Information (FCI) Record contains the information that is returned when a MEL application is selected. MULTOS stores the FCI Record and returns the information if required during a Select File command. Each MULTOS implementation will have a maximum size for a FCI record and it should be formatted according to the ISO 7816-4 standard.

Application Signature The Application Signature is a signed hash of the Application Unit and provides the ability to verify that the Application correctly loaded onto the MULTOS Card. It checks that the ALU has not been corrupted or tampered with. The Application Signature is stored within the ALU using the first two bytes to hold the length followed by the Application Signature itself. An Application Signature is present in Protected and Confidential ALU.


GALU

KTU The Key Transformation Unit contains the information needed by the MULTOS Card to decipher any ciphertext within the ALU. The KTU itself is enciphered using the Target MULTOS Card’s Public Key. Only the Target MULTOS Card will have the corresponding private key to decipher the KTU. Any ALU with a Key Transformation Unit is specific to a single MULTOS Card and only this card is able to decipher the KTU and thereby decipher the encrypted portions of the ALU.

Structure of the Application Unit The Application Load Unit is the information that we send to the card. When the input reaches the card it is actually stored in a slightly different format, called the Application Unit. So the Application Unit represents the structure that a MULTOS Card uses when an application has been loaded. It is way that the application is stored on the card. The following diagram shows the process of converting an Application Load Unit into an MULTOS 4 Application Unit.

code record

code record

data record

data record

dir record

dir record

fci record

fci record

Mcd_Number




KTU

Components

Application Load Unit Application Unit

Application Unit The format of the Application Unit is unimportant in terms of the load procedure, but is important when we start looking at the generation of the KTU (and signature). When encrypting the code and data, we need to consider the fact that the decryption (done by the MULTOS card) of the loaded code and data is done in continuous blocks and does not consider the original nature of the data as it was loaded. Therefore we must encrypt the hex block (code and/or data) as though it were on the card already. This means that the hex will be decrypted to valid code/data. Notes on MULTOS v3: The format of a MULTOS v3 Application Unit (the information as stored on the card) is slightly more complex. It is shown below and explained in more detail later.

code record49 bytes 00

data record

dir recorddir record length

lengthfci record

fci record

64 bytes

Multiple of 32 bytes

Padding

Padding



Example: It is possible to encipher the whole of the code record, and the first portion of the data, in a block of enciphered data. A second block of data could be enciphered using a different key.

Generation of the Key Transformation Unit This section details the process involved in generating a Key Transformation Unit, the mechanism for enciphering Application Load Units. If Protected, not Confidential ALU, are going to be used then this section can be ignored.

Overview A Key Transformation Unit (KTU) contains information on how any enciphered portions of the Application Load Unit have been enciphered. As such, the first task in generating the KTU is to decide how the Application Load Unit is to be enciphered. A Plaintext KTU is created which holds a list of areas enciphered along with the algorithm identifier and key(s) used to encipher the required area. This Plaintext KTU is then enciphered to generate the Ciphertext KTU. The key used to encipher the Plaintext Key Transformation Unit is the Target MULTOS Card’s Public Key. This requires that the KTU is created specifically for a single MULTOS Card, the Target Card, and the Public Key of this card must be known. This Public Key is often referred to as the MCD Public Key.

Procedure The following is an overview of the process involved in generating a Key Transformation Unit.

The secret portions of the ApplicationUnit are enciphered and theregions, algorithm and keys usedstored in the plaintext KTU.

The Unprotected ALU is converted toan Application Unit which is used toperform enciphering on.

Plaintext KTU is enciphered usingMCD Public Key

The enciphered application Unitis copied back into the ALU.

The Ciphertext KTU is then copied tothe ALU..

Unprotected ALU

Application Unit

Plaintext KTU

Ciphered Application Unit

Ciphertext KTU

KTU

e(KTU) KTU

MCD Public Key

E

E

MEL MEL

MELMEL

The Key Transformation Unit details which areas of the ALU code and data are enciphered and which keys where used. The KTU itself is therefore also enciphered in order to protect the keys contained within it.


GALU

Note that the Application Unit is not the same as the Application Load Unit (ALU). Although it contains essentially the same information the ordering of the information is important and they must be considered different. In section 0 the differences between the application load unit and the application unit were explained and these are going to be important because we will be enciphering parts of the application unit structure.

Plaintext KTU Overview The Plaintext Key Transformation Unit is generated from information which defines the areas of the ALU which have been enciphered along with the algorithm identifier and key(s) used for each enciphered area. The following diagram shows the structure for the Plaintext Key Transformation Unit.

code record data recorddir record fci record

Application Unit

area start 1area start 2

Key1 Key2

area length 1 area length 2

Algorithm IDArea StartArea LengthKey Data LengthKey Data


Area Descriptor 1PlaintextKTU

KTU Header

Padding

Area Descriptor 2

The following diagram shows how some of the fields apply to an Application Unit that either has been or will be enciphered. The sub-box within this next diagram shows the structure of each area descriptor.

Set MSM Controls Data DateInitial Padding

Mcd_NumberApplication_IDNo Area Descriptors

padding


811

1711221xx



KTU Header The KTU header consists of the following components:

• Initial Padding: This is a single byte, set to ‘55’, which is present to ensure that the most significant bit of the Plaintext Key Transformation Unit is zero.

• Set MSM Controls Data Date: This is the byte that represents the date on which the MSM Controls Data for the Target MULTOS Card(s) were created. The byte corresponds to the number of months since January 1998.

• MCD Number: This is the identification number for the Target MULTOS Card. Each Key Transformation Unit must be created for a specific MULTOS Card and this identifies the card.

• Application ID: The Application ID of the application contained within the ALU (or Application Unit). This is held as three fields: Length of the AID, the actual AID and padding of ‘FF’ to make the length of the whole field equal to 17 bytes.

• No. Area Descriptors: The number of blocks that are to be enciphered. The maximum number of blocks depends upon the algorithms used and the size of the card’s Public Key.

• Area Descriptors: See below for details of an Area Descriptor structure. • Padding: The Plaintext KTU must be padded such that its size is equal to the size of the MCD

Public Key. This padding should be formed from random numbers. There is a limit on the size of the KTU Ciphertext, which is the size of the MULTOS Card’s Public Key, e.g. 72 bytes. This limits the number of blocks that can be enciphered within the application unit itself. For a MULTOS v4 card the following should at least be possible:

• Two DES CBC blocks • One Triple DES CBC block • One Triple DES CBC and one DES CBC block

The Plaintext KTU contains all of the information required to decipher the encrypted blocks of the Application Unit, including the keys used. It clearly must be protected to prevent this information from being seen. Enciphering the Plaintext KTU with the Public Key of the Target MULTOS Card does this. Area Descriptors An Area Descriptor refers to a block of the Application Unit that has been enciphered. The Area Descriptor stores the location of the block, the manner in which it was enciphered and the key(s) used. The following is a list of the fields in each Area Descriptor:

• Algorithm ID: This specifies the algorithm used to encipher the block. Currently only DES CBC (ID = ‘01’) and triple DES CBC (ID = ‘02’) are allowed.

• Area Start: This is the starting byte of the encrypted area, relative to the start of the Application Unit.

• Area Length: This is the number of bytes in the block, and must be in multiples of 8 when doing DES CBC encryption

• Key Data Length: This holds the number of bytes in the key data. This is ‘08’ for single DES CBC and ‘10’ for 2-key triple DES CBC.

• Key Data: This holds the key(s) themselves.


GALU

Ciphertext Application Unit The Application Unit must have the secret areas enciphered using the algorithm and keys specified in the Area Descriptors.

E E

code record

code record

data record

data record

dir record

dir record

fci record

fci record

Application Unit

Application Unit

Note that the Application Unit is a representation of how MULTOS will see the application as it is loaded, and is therefore the structure which MULTOS will use when deciphering any enciphered areas. The whole process of enciphering the Application Load Unit is designed to reduce the processing required by the MULTOS Card and hence increase load speed. Once the Ciphertext Application Unit has been generated the Ciphertext is copied back into the original Application Load Unit. The ciphertext will occupy the same space as the original plaintext. An Application Signature will always be required when a KTU is used and the Ciphertext Application Unit should be retained for calculating the Application Signature.

Ciphertext KTU Enciphering the Plaintext KTU with the Public Key of the Target MULTOS Card generates the Ciphertext KTU, as shown in the following diagram.

Random padding is added to thePlaintext KTU such that it equals thesize of the MCD Public Key.

Plaintext KTU + Padding isenciphered using the MCD PublicKey.

Plaintext KTU Padding

MCD Public Key ERSA

Ciphertext KTU

For the registration of MULTOS version 4 applications a hash of the code must be sent to the MULTOS CA. If a KTU is used to encipher the code area of the application then a hash of this enciphered code area must be sent. This also means that the any area that is enciphered, and contains code, should not run over into the data area. If it does that changing any data will change the enciphered result, and hence change the code hash, requiring a new hash will have to be calculated and registered every time the data changes.



Generation of the Application Signature The Application Signature is a Signed Hash Digest of the Application Unit. By providing a Hash Digest of the Application it is possible for the MULTOS Card to verify that the application has not been corrupted or tampered with. By providing a Signed Hash Digest it is possible for the MULTOS Card to verify the authenticity of the Hash Digest itself. Please note that an application signature alone does not prevent the examination of the code and data within the Application Load Unit as, in that case, none of code and data are enciphered. The key used to sign the Hash Digest is the Application Provider’s Private Key, which only the Application Provider knows. The Issuer, as part of the Application Load Certificate request, sends the Application Provider’s Public Key to the MULTOS KMA. This is included within the Application Load Certificate and the MULTOS Card can therefore verify the authenticity of the Application Signature itself.

Procedure The following diagram is an overview to the process of generating an Application Signature.

MEL

Sig

MEL

Application Unit is hashed using Asymmetric Hash

Application Unit is generated

Hash is signed using the Application Providers Private Key

Hash Digest is padded to equal the size of the Application Providers Private Key.

Signature is added to the end of the Unprotected ALU to form a Protected ALU

Hashing Algorithm

Signing Algorithm


Hash Digest Padding

Application Providers Private Key

Sig Sig

H

E

Unprotected ALU

Application Unit Ciphered

Application Unit

MEL MEL

MEL

MEL

Note that the Application Unit is not the same as the Application Load Unit (ALU). Although it contains essentially the same information the ordering of the information is important and they must be considered different. In section 0 the differences between the application load unit and the application unit were explained and these are going to be important because we will be calculating the hash digest over the application unit structure.


GALU

Calculating the Hash Digest The following diagram shows the process of calculating the Hash Digest for the Application Signature for a MULTOS 4 card. The hash digest calculation is done in two steps. The first, using a fixed initial vector, results in a 16-byte hash digest value of the application unit. The second step uses this hash digest value as its initial vector. The input data for the second hash is a block of 0x55 equal to Application Provider’s key modulus length minus the size of the final AHASH digest length and also minus two 8-byte padding blocks; i.e., the length of the input data would be (application provider’s key modulus length – 32). So, in the case of a 128-byte modulus, the input data would be a 96-byte block of ‘55’. The asymmetric hash algorithm is a chain block cipher that makes use modular exponentiation. So, the data must be handled in blocks. The block size is the hash modulus size minus the AHASH digest size; i.e., hash modulus size – 16. For this example, the modulus size is 72 bytes, which gives a block size of 56 bytes. In order for the chain block modular exponentiation to work properly, it is necessary that the input data length be an integer multiple of the block size and that the integer representation of each block of the message be smaller than that of the modulus. To ensure that both conditions are met the initial input data block needs to have enough bytes of ‘55’ prepended so that the input data length is divisible by the block size. In the case of the first step of calculating the hash digest for the AU Signature do not confuse the prepended ‘55’ bytes with the Hash function initial vector, which is a 16-byte block of ‘55’. In the case of the second step, the resulting input block will be one composed entirely of ‘55’, which is then divisible by the block size. To continue with the example of a 128-byte modulus the initial input data to the second step is 96 bytes of ‘55’. As 96 is not divisible by the block size of 56, the data must have enough bytes of ‘55’ prepended so that the input is a multiple of 56. So, by adding 16 bytes of 0x55 the resulting block is 112 bytes of ‘55’.



H

H

Application Unit

1st A-Hash

2nd A-Hash

MEL

0x55 ... 0x55

0x55 ... 0x55

Initial Value

Initial Value

Application Hash The Hashing Algorithm is an Asymmetrical Hash, described in the following section. The signing process involves exponentiation of the plaintext using the Application Provider’s Secret Key.


GALU

Hashing Algorithm The Application Unit is hashed using the following MULTOS Hash Digest algorithm.

Hash Modulus

Application Unit

Blocks for the hash

Unprotected ALU

Hash Digest

E

The Hash is an RSA Cipher performed over each of the Application Unit blocks. The key used to perform this cipher is the Hash Modulus.

The algorithm is chained with each block being used to generate the next block. This continues until all blocks have been used.

The Hash Digest is equal to the most significant bits of the final ciphered block.

The Application Unit is split into blocks. These blocks are then added to the most significant bits of the last result and passed though an RSA cipher.

Each block is appended to the Current Chain Value, or to the Initial Value for the first block, before being enciphered using RSA with the hash Modulus as the key.

The Application Unit is generated from the Unprotected ALU. Padding may have to be added to the beginning of the AU.

RSA

Initial Value

Current Chain Value

Hash Chain

Current Block

Block 1 Block 2 Block n

RSA CipherText

Most Significant Bits

Loop overall blocks

finished

Split message into blocks The length of the Hash Digest produced from the algorithm is fixed at 16 bytes. The Hash Modulus is the key used to perform the RSA encryption and is set by the MULTOS CA. The 72-byte hash modulus, with a public exponent of 3, for some of the development cards is:

E45D04F70555C571C41262B961FCFE2E EA1BD440BE6432DCE109E1B271E3E4F9 680B4573321EC95A0B236F4219E40B18 A936EE7502411D75FE8F7B34506DB0B5 563CFDE7CDBB52E1

Note that the details of the various modulus keys for the various development masks can be found in the Developer Card: User Guidelines.



The length of the blocks into which the message must be split may be calculated by subtracting the hash modulus size from the hash digest size. In this case the hash modulus size is 72 bytes and the hash digest size is 16 bytes. So, the block size is 72 – 16 = 56 bytes. The following diagram shows the relationship between the length of the Hash Modulus, the 16 byte Hash Digest and the Block Length. The following diagram shows the sizes that must be used for the blocks within the hashing algorithm.

Hash Modulus

Hash Digest

Hash Chain Current Block

Block

The Block Length is equal to theLength of the Hash modulusminus the size of the Hash Chain.

The size of the data block to beenciphered is equal to the size ofthe RSA Key: the Hash Modulus.

The size of the final Hash Digest, orhash, is equal to the size of thehash chain.

If the message is not a multiple of the Message Block Length then padding bytes of ‘55’ must be prepended to the message such that the resulting length is divisible by the block size. The algorithm used to perform the hash may vary in later versions of MULTOS. There is no provision within the ALU to specify the algorithm used and therefore it must be derived from knowledge outside the scope of this document. When generating an ALU, the version of MULTOS for which the ALU is to be used must be known. Encipher blocks Each block in the message is then enciphered using the Hash Modulus. The block is concatenated to the current Hash Chain value. Due to the limitation of the RSA calculation that the value of message (m) and modulus (n) should obey the rule: m < n, the Most Significant Bit (MSB) of the message is set to 0, since the MSB of the hash modulus is always 1. Therefore during (for the new Hash Chain value), and after enciphering (for the result), the Most Significant Bit in the result must be set to zero. An Initial Value is used as the first block to be enciphered in the Hash Chain. The last Hash Chain value generated is the final result of the asymmetrical hash algorithm.


GALU

Signing the hash The Hash Digest and Padding is signed using the Application Provider’s Private Key using the RSA algorithm as shown below.

Random padding is added to the Hash Digest such that it equals the size of the App Provider Private Key..

Hash Digest + Padding is enciphered using the App Provider Private Key.

Hash Digest Padding Padding Padding

Application Provider Private Key E

RSA


MEL

FixedRandom

The Random Padding added to the Hash Digest protects the Application Provider’s Private Key from crypto-analysis. When the Application Signature is verified on the MULTOS Card the length of the Hash Digest is known and the Random Padding is simply discarded. In addition there should be 8 bytes of fixed padding added.

Application Provider Private Key The key used during the signing of the Hash Digest is the Application Provider’s Private Key. The Application Provider must generate a pair of asymmetric keys. The Issuer must supply the public key to the MULTOS CA and it is then included within the Application Load Certificate. The private key is not disclosed and is used to sign the Hash Digest and so form the Application Signature. Only a valid Application Load Certificate, with the correct Application Provider’s Public Key, is able to correctly verify an Application Signature, and only the Application Provider, who knows the Private Key, is able to generate an Application Signature.

Application Signature Once the Application Signature has been generated it is inserted directly into the Application Load Unit.



MULTOS V4 Confidential ALU This section contains a complete example of generating a confidential Application Load Unit for any MULTOS 4 developer card except the Keycorp SLE66 1N’. This is so because the Transport Key Certification Key (tkck_pk) used are different from all other MULTOS 4 cards. Previous versions of this document contained in formation on generating ALU for those cards that used the MULTOS 3 structures. This is no longer present, but if required, the information can be obtained from developer support. In this example the entire data component of the application load unit is enciphered. In addition to this encryption, the application load unit will also have an Application Signature to prevent the application load unit from being corrupted or tampered with before being loaded onto a MULTOS Card.

Plaintext Application Load Unit The following is the unprotected application load unit. This is formed from six components, and the application signature and ciphertext KTU components are empty. These shall be added later in the example. Code component

3F 01 FF F3 70 00 09 03 05 6E 00 3F 01 FF F4 70 10 09 03 05 6D 00 26 21 02 28 01 5E 00 00 59 00 00 29 0E 40 06 00 40

Data component

4D 55 4C 54 4F 53 20 2D 20 74 68 65 20 63 6F 6D 70 6C 65 74 65 20 73 6F 6C 75 74 69 6F 6E 2E 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

DIR record entry component

61 0E 4F 01 0A 50 09 61 54 65 73 74 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

FCI record component

01 02 03 04 05 06 07 08 01 02 03 04 05 06 07 08 01 02 03 04 05 06 07 08 01 02 03 04 05 06 07 08

Application Signature component

{empty} Ciphertext KTU component

{empty}


GALU

Plaintext Application Unit The first step in the process is to convert the application load unit into an Application Unit. The Application Load Unit is the file format that is used to store the application in a file on a PC. The Application Unit is a snap shot of the application as the MULTOS Card will see it when loaded onto the card. All of the encryption and signature generation is carried out using the application unit and not the application load unit. . The application unit is generated using the binary data from the application load into the following structure:

code record

data record

dir recordfci record

The following shows the transformation of an application load unit into an application unit.

code record

code record

data record

data record

dir record

dir record

fci record

fci record

Mcd_Number




KTU

Components

Application Load Unit Application Unit

Application Unit The Application Unit would consist of the following components. DIR record entry component

61 0E 4F 01 0A 50 09 61 54 65 73 74 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

FCI record component

01 02 03 04 05 06 07 08 01 02 03 04 05 06 07 08 01 02 03 04 05 06 07 08 01 02 03 04 05 06 07 08

Code component

3F 01 FF F3 70 00 09 03 05 6E 00 3F 01 FF F4 70 10 09 03 05 6D 00 26 21 02 28 01 5E 00 00 59 00 00 29 0E 40 06 00 40

Data component

4D 55 4C 54 4F 53 20 2D 20 74 68 65 20 63 6F 6D 70 6C 65 74 65 20 73 6F 6C 75 74 69 6F 6E 2E 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00



Combined Application Unit The following is the original example application load unit once it has been converted to a MUTLOS Version 4 Application Unit.

61 0E 4F 01 0A 50 09 61 54 65 73 74 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 02 03 04 05 06 07 08 01 02 03 04 05 06 07 08 01 02 03 04 05 06 07 08 01 02 03 04 05 06 07 08 3F 01 FF F3 70 00 09 03 05 6E 00 3F 01 FF F4 70 10 09 03 05 6D 00 26 21 02 28 01 5E 00 00 59 00 00 29 0E 40 06 00 40 4D 55 4C 54 4F 53 20 2D 20 74 68 65 20 63 6F 6D 70 6C 65 74 65 20 73 6F 6C 75 74 69 6F 6E 2E 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Enciphering Application Units For the purposes of this example, the data component of the application load unit will be enciphered. The following is a hex dump of the data component of the sample Application Load Unit we are considering:

4D 55 4C 54 4F 53 20 2D 20 74 68 65 20 63 6F 6D 70 6C 65 74 65 20 73 6F 6C 75 74 69 6F 6E 2E 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

The algorithm used to encipher this block of data is actually a DES Chain Block Mode decipher. There is some logic in this. Early versions of MULTOS could only encipher, so the decipher algorithm was performed off-card, so that the card need only encipher. When the application is loaded the MULTOS Card will use a DES Chain Block Mode encipher function to decipher the plaintext. The enciphering may be performed using either single or triple DES chain block mode enciphering. The following diagram shows how a block of plaintext is encrypted (actually using the decipher algorithm) to form part of the ciphertext application unit.


GALU

The encryption process The following are more detailed workings for the first three blocks of the chained decipher. The first block is a simple decipher. Subsequent blocks are then XOR’d with the previous ciphertext block before being deciphered. DES Key = 41AD8223A90BE2A1

Input Output DES CBC Decryption of first eight bytes data DESCBCDec(4D554C544F53202D)

6BC8592212B0495A

2nd plaintext block XOR previous ciphertext block 2074686520636F6D XOR 6BC8592212B0495A

4BBC314732D32637

DES CBC Decryption of result DESCBCDec(4BBC314732D32637)

7AD431DA01BF7EBE

3rd plaintext block XOR previous ciphertext block 706C65746520736F XOR 7AD431DA01BF7EBE

0AB854AE649F0DD1

DES CBC Decryption of result DESCBCDec(0AB854AE649F0DD1)

190A89307E40D288

... The generated ciphertext component is shown in BOLD in the table above, and in full here:

6B C8 59 22 12 B0 49 5A 7A D4 31 DA 01 BF 7E BE 19 0A 89 30 7E 40 D2 88 C2 00 AF D6 48 6E F6 E2 8B 0E 2E A9 69 C0 B1 46 B5 60 C4 10 C9 36 5C 00 C3 91 52 E6 06 6E EA 36 34 1F 9E 24 5C 0F 44 42

The enciphered data is placed back into the application unit. This is required for the generation of the application signature detailed later in this example.

Retrieval/Authentication of MULTOS Card Public Key Before we can generate the Ciphertext KTU, we must retrieve and authenticate the MULTOS Card Public Key from the certificate returned by the Open MEL command. The Public key Certificate may be obtained from the MULTOS Controls Data returned from the MULTOS CA to enable a MULTOS Card. Alternatively a MULTOS Card, once enabled, will return its public key certificate in response to an Open MEL Application APDU command. This example assumes that the certificate has already been obtained and demonstrates how the certificate can be authenticated and the key retrieved. This example also assumes that the public portion of the Transport Key Certifying Key (tkck_pk) used by the MULTOS CA to sign the certificate has also been obtained. The public key certificate will have a Key Header and the Public Key itself. MULTOS has various different public keys (e.g. MULTOS Card PK, Application Providers PK), and the structure of the Key Header is specific to the particular public key type. However it will always contain information that relates to the use of the key. For example, a MULTOS Public Key Certificate will contain information about the MULTOS Card whilst a Application Providers Public Key Certificate will contain information about an application.



The plaintext version of the certificate consists of the length of the public key certificate, followed by the Key Header, followed by the Public Key, and followed by sixteen bytes of padding (eight random, eight fixed). The following is a hex dump of the entire certificate. Raw MULTOS Public Key Certificate Hex Dump

00 A8 50 00 11 22 33 44 55 66 77 01 01 00 04 00 60 00 80 00 00 01 03 00 00 00 FF 11 00 00 01 00 FE F1 80 03 FF F3 FF F1 33 9B B7 7F F1 9E 35 9B EE 9D 9B 98 64 74 12 1C C1 D0 48 56 A9 39 33 C1 79 33 CD CC 12 4B 30 BE AE 8F 0F C6 D1 9D D1 60 94 D4 DE C9 CD 32 53 27 4C F9 4B 98 7E A4 CF 80 DA 7D 58 49 F2 D0 C6 48 FB 75 BE 7A A3 44 7D D9 5E 36 BA 06 AC 1F FD 6E A7 A9 7B EE AB 0B EB 98 11 E8 33 AE 3C 5D 7D 4F 57 3C E9 A6 46 7C EC 5D 68 68 26 B9 68 D5 95 80 BA BF 4D 09 55 68 B4 0D FD BC 2C 80 64 C5 2F 25

Formatted MULTOS Public Key Certificate Hex Dump The following is a hex dump of the certificate with the different fields within the certificate separated. Field value certified_public_key_length 00 A8 key_type 50 (1) key_identifier 00 11 22 33 44 55 66 77 certification_method_id 01 01 hash_method_id 00 04 public_key_length 00 60 certifying_key_length 00 80 algorithm_id 00 exponent_length 00 01 public_exponent 03 00 00 00 mcd_issuer_product_id FF mcd_issuer_id 11 00 00 01 set_msm_controls_data_date 00 mcd_number FE F1 80 03 FF F3 FF F1 (pk_top) + Ciphertext (2) (1) The key type value of ‘50’ indicates a MULTOS public key certificate (2) The PK Top and Ciphertext value is:

33 9B B7 7F F1 9E 35 9B EE 9D 9B 98 64 74 12 1C C1 D0 48 56 A9 39 33 C1 79 33 CD CC 12 4B 30 BE AE 8F 0F C6 D1 9D D1 60 94 D4 DE C9 CD 32 53 27 4C F9 4B 98 7E A4 CF 80 DA 7D 58 49 F2 D0 C6 48 FB 75 BE 7A A3 44 7D D9 5E 36 BA 06 AC 1F FD 6E A7 A9 7B EE AB 0B EB 98 11 E8 33 AE 3C 5D 7D 4F 57 3C E9 A6 46 7C EC 5D 68 68 26 B9 68 D5 95 80 BA BF 4D 09 55 68 B4 0D FD BC 2C 80 64 C5 2F 25


GALU

This is 128 bytes. We are unable to determine what the end of this certificate is at the moment. Until we know the size of the MULTOS KMA Transport Key Certifying Key, we can not determine how much of the end of the certificate is ciphertext and how much is pk_top.

Recovering the Public Key Most (if not all) of the public key (modulus) is held within the ciphertext at the end of the certificate. To decipher this ciphertext requires the public part of the MULTOS CA Transport Key Certification Key (tkck_pk). The Public Exponent portion of the public key is held in the plaintext portion of the certificate, public_exponent, above. The value of the tkck_pk used in this example is as follows: Public Exponent

03 Public Modulus (tkck_pk)

B6 E7 AA 2B 4E 29 96 F1 A9 1E A7 4F 49 7A E4 AF 5E C8 75 C2 88 FA 5F 16 70 26 66 F1 BB FC 6C 5F 30 9C 1E 17 6A C1 D0 23 8F A6 A9 8E 63 42 7E AA D6 F5 E6 FF 54 0A AB CE 41 2E 74 78 A4 9B 93 AE CA E5 EF E6 31 13 8A 49 45 D7 B2 27 C6 1A 62 20 74 2F 7F 24 12 61 77 FC 9C 15 01 C9 59 C3 34 C8 06 13 86 63 7F 36 DD 49 0C 2E 6E 33 C5 36 EF 9D EC CD 73 27 4B 27 13 5D 93 52 F7 1C 37 95 AB A7

This key is the developer tkck_pk and not the live tkck_pk. This key is valid for use with MULTOS Test Development Cards, but not with live cards. This is 128 bytes which is used to decrypt the bottom of the ciphertext. The ciphertext portion of the MULTOS certificate is therefore, in fact, all of the ciphertext. The length of pk_top is zero. Decypting the Ciphertext we get:

14 55 F8 E6 A5 02 BA 4D 2C 1E 1A E8 B8 1C 47 0C C2 6C 29 42 65 A6 5C 94 F1 BC 91 16 BA 4A 60 10 EC 0F 91 AE 1F 8B 7E E5 96 4D BD 61 A2 22 25 6C B8 1E A1 2D 5D 66 07 E4 B7 51 AF 26 C4 AB 4A D7 1A 19 3F C1 5C 4A A3 52 E1 1F 0A C4 B9 0E 1F 84 AB 6D 20 AA 0E 49 8F 25 07 98 56 1B 46 73 9A 60 D6 18 48 C0 70 9E B7 4D C3 53 AC FF F0 66 19 A5 E9 E9 FA 0C 70 07 A2 5B 55 55 55 55 55 55 55 55



Interpretation of decrypted certificate ciphertext The following is the interpretation of the plaintext. It is a concatenation of a 16 byte Hash Digest, the 96 bytes of the public key (modulus), 8 bytes of random padding and 8 bytes of fixed padding. Plaintext = Hash Digest || Key || Padding Hash Digest

14 55 F8 E6 A5 02 BA 4D 2C 1E 1A E8 B8 1C 47 0C Whole of Card’s Public Modulus

C2 6C 29 42 65 A6 5C 94 F1 BC 91 16 BA 4A 60 10 EC 0F 91 AE 1F 8B 7E E5 96 4D BD 61 A2 22 25 6C B8 1E A1 2D 5D 66 07 E4 B7 51 AF 26 C4 AB 4A D7 1A 19 3F C1 5C 4A A3 52 E1 1F 0A C4 B9 0E 1F 84 AB 6D 20 AA 0E 49 8F 25 07 98 56 1B 46 73 9A 60 D6 18 48 C0 70 9E B7 4D C3 53 AC FF F0 66 19 A5

Random Padding

E9 E9 FA 0C 70 07 A2 5B Padding

55 55 55 55 55 55 55 55

Authenticating the certificate The Hash Digest is an Asymmetrical Hash of the certificate header. In order to authenticate the certificate the hash digest recovered from the certificate must match the digest of the header. Like the generation of the Application Signature, this is done with two asymmetric hashes but the 2nd Hash is done on public bottom, not a block of ‘55’. Plaintext Header

00 A8 50 00 11 22 33 44 55 66 77 01 01 00 04 00 60 00 80 00 00 01 03 00 00 00 FF 11 00 00 01 00 FE F1 80 03 FF F3 FF F1

Note: There is no top of the Public Key to include here but with different key sizes there might be. This prepended with bytes of ‘55’ to pad to a multiple of 56 bytes gives one block

55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 00 A8 50 00 11 22 33 44 55 66 77 01 01 00 04 00 60 00 80 00 00 01 03 00 00 00 FF 11 00 00 01 00 FE F1 80 03 FF F3 FF F1


GALU

Prepending this with an initial value of 16 bytes of ‘55’ gives

55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 00 A8 50 00 11 22 33 44 55 66 77 01 01 00 04 00 60 00 80 00 00 01 03 00 00 00 FF 11 00 00 01 00 FE F1 80 03 FF F3 FF F1

Using the RSA key for the hash modulus function gives

1B 35 DB F5 23 AE 18 68 76 D9 38 77 A7 60 9A 34 D6 CF 53 7F 81 12 77 7A 42 7D 70 6D BD 05 8E B0 56 75 A3 EB 91 F2 FC 90 A9 05 3C 94 1C 85 A0 FD 2F 80 E9 43 60 67 D2 C7 83 2D C0 16 96 83 9A B9 E8 5D C5 8E 99 B8 8D DC

The first sixteen bytes, with MSB set to 0 is 1B35DBF523AE186876D93877A7609A34. 1st A-Hash The 1st A-Hash of this is calculated to be

1B 35 DB F5 23 AE 18 68 76 D9 38 77 A7 60 9A 34 This value is then used as the initial value of the 2nd asymmetric hash, which is performed on the public modulus. Since the bottom of the public modulus is greater than 56 bytes (a single block) we must split it in to multiple blocks with the first prepended with ‘55’. Note that this is not the same as Application Signature Generation, where the second hash is performed on a block of ‘55’. So for this example the bottom of public split in to blocks of 56 prepended with ‘55’ gives us two blocks

55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 C2 6C 29 42 65 A6 5C 94 F1 BC 91 16 BA 4A 60 10 EC 0F 91 AE 1F 8B 7E E5 96 4D BD 61 A2 22 25 6C B8 1E A1 2D 5D 66 07 E4

and

B7 51 AF 26 C4 AB 4A D7 1A 19 3F C1 5C 4A A3 52 E1 1F 0A C4 B9 0E 1F 84 AB 6D 20 AA 0E 49 8F 25 07 98 56 1B 46 73 9A 60 D6 18 48 C0 70 9E B7 4D C3 53 AC FF F0 66 19 A5



The concatenated block is (Initial Value (1st A-Hash) + block 1) is

1B 35 DB F5 23 AE 18 68 76 D9 38 77 A7 60 9A 34 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 C2 6C 29 42 65 A6 5C 94 F1 BC 91 16 BA 4A 60 10 EC 0F 91 AE 1F 8B 7E E5 96 4D BD 61 A2 22 25 6C B8 1E A1 2D 5D 66 07 E4

Performing RSA on the first block gives

97 5D 84 32 35 47 2B B2 22 4A 38 78 76 B6 8F 9B 3D 7F 33 72 64 81 A4 31 81 2A 75 2B BD 49 49 46 A1 6B 79 F1 7C AF 92 39 75 BD 80 54 09 70 87 B3 2C 2A 9C 13 E3 40 5A 40 C2 C1 71 C6 A0 56 DF D2 B6 67 84 3C 73 5F A4 67

We must set the MS bit to 0 so second IV is 175D843235472BB2224A387876B68F9B. Second concatenated block is

17 5D 84 32 35 47 2B B2 22 4A 38 78 76 B6 8F 9B B7 51 AF 26 C4 AB 4A D7 1A 19 3F C1 5C 4A A3 52 E1 1F 0A C4 B9 0E 1F 84 AB 6D 20 AA 0E 49 8F 25 07 98 56 1B 46 73 9A 60 D6 18 48 C0 70 9E B7 4D C3 53 AC FF F0 66 19 A5

Performing RSA gives

14 55 F8 E6 A5 02 BA 4D 2C 1E 1A E8 B8 1C 47 0C A2 B6 3E D7 95 DC DE B8 06 98 4E 6F 4E 9D E9 F3 94 A5 DF 76 6B F4 E5 96 B8 A6 FD CE D3 16 56 B5 1A E8 18 46 CB B6 D3 30 0F D4 C8 09 BF 8B 81 C7 4F 8C F4 9C 95 10 D1 3E

The first sixteen bytes, with MSB set to 0 is 1455F8E6A502BA4D2C1E1AE8B81C470C 2nd A-Hash The second A-HASH value is

14 55 F8 E6 A5 02 BA 4D 2C 1E 1A E8 B8 1C 47 0C This value matches the Hash Digest retrieved from the Ciphertext Certificate and therefore the certificate is authentic and the extracted key can be used.


GALU

Generation of Ciphertext KTU The Ciphertext KTU component of the application load unit must now be generated. This holds the information about what parts of the application unit have been enciphered and which algorithm and keys have been used to encipher the application unit. . Field Value Initial Padding 55 MSM Date 00 MCD Number FE F1 80 03 FF F3 FF F1 Application ID AID Length 01 AID 0A AID Padding FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF No Area Descriptors 01 Area1 Algorithm ID 01 Area1 Start 00 67 Area1 Length 00 40 Area1 Data Len 08 Area1 Key Data 41 AD 82 23 A9 0B E2 A1 Note: When attempting to replicate this process on MULTOS developer cards, the MSM Date and MCD Number must match those on the card. Not necessarily those values quoted here. The following shows the above data after being assembled into a single block of data and padded to the 96 bytes length of the MULTOS Cards Public Key.

55 00 FE F1 80 03 FF F3 FF F1 01 0A FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 01 01 00 67 00 40 08 41 AD 82 23 A9 0B E2 A1 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Note: The padding must be random for the security of the ALU to be maintained. For the purposes of clarity a padding value of 0x00 has been used in this example



The plaintext KTU is enciphered using the MULTOS Card’s Public Key (the Public Modulus and exponent from the last section). This key may be obtained from the MULTOS Cards Public Key certificate. For the development card used in this example the value of the key is: Public Exponent

03 Public Modulus (multos_transport_key)

C2 6C 29 42 65 A6 5C 94 F1 BC 91 16 BA 4A 60 10 EC 0F 91 AE 1F 8B 7E E5 96 4D BD 61 A2 22 25 6C B8 1E A1 2D 5D 66 07 E4 B7 51 AF 26 C4 AB 4A D7 1A 19 3F C1 5C 4A A3 52 E1 1F 0A C4 B9 0E 1F 84 AB 6D 20 AA 0E 49 8F 25 07 98 56 1B 46 73 9A 60 D6 18 48 C0 70 9E B7 4D C3 53 AC FF F0 66 19 A5

The resulting ciphertext KTU is shown in the following hex dump. This is the actual component that is appended to the application load unit: Ciphertext KTU

09 09 1C C6 7C BE 04 18 6A D6 B6 96 E3 8E C6 6B 18 B3 E3 B7 30 95 11 69 40 25 D5 46 E7 3E E3 39 A3 41 63 6C 2E 14 84 8A D0 A6 BE E2 0E A4 18 8E 20 EA 90 B0 EC EE 2A E4 24 D8 5E 85 E9 31 BE A7 05 4F 84 79 B0 D9 B1 07 36 0D C9 3A 2B C8 48 9A 58 24 36 A0 C6 49 7A 06 D2 8C 44 3F 68 02 EA 44

For the registration of MULTOS version 4 applications a hash of the code must be sent to the MULTOS CA. If a KTU is used to encipher the code area of the application then a hash of this enciphered code area must be sent. This also means that the any area that is enciphered, and contains code, should not run over into the data area. If it does that changing any data will change the enciphered result, and hence change the code hash, requiring a new hash will have to be calculated and registered every time the data changes.


GALU

Generation of the Application Signature The encrypted area(s) replace the plaintext in the application unit. The application signature is then generated using the encrypted area and not on the original plaintext application unit. The following is a hex dump of the application unit after the data component has been enciphered. In this case the last 64 bytes of the application has been ciphered.

61 0E 4F 01 0A 50 09 61 54 65 73 74 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 02 03 04 05 06 07 08 01 02 03 04 05 06 07 08 01 02 03 04 05 06 07 08 01 02 03 04 05 06 07 08 3F 01 FF F3 70 00 09 03 05 6E 00 3F 01 FF F4 70 10 09 03 05 6D 00 26 21 02 28 01 5E 00 00 59 00 00 29 0E 40 06 00 40 6B C8 59 22 12 B0 49 5A 7A D4 31 DA 01 BF 7E BE 19 0A 89 30 7E 40 D2 88 C2 00 AF D6 48 6E F6 E2 8B 0E 2E A9 69 C0 B1 46 B5 60 C4 10 C9 36 5C 00 C3 91 52 E6 06 6E EA 36 34 1F 9E 24 5C 0F 44 42

The first task is to generate the Asymmetrical Hash of the application unit. For MULTOS version 4 cards, the Hash Digest is calculated in two steps. The first is to perform an A-Hash on the application unit. The next step is to use the result from this A-Hash as the Initial Value for a second A-Hash. The second A-Hash is applied to a block of ‘55’.

H

H

Application Unit

1st A-Hash

2nd A-Hash

MEL

0x55 ... 0x55

0x55 ... 0x55

Initial Value

Initial Value

Application Hash We need to split the above block (Application Unit) into blocks of 56. If we need to pad then they need to be placed at the beginning of the block. The pad byte is ‘55’.



Above we have 167 bytes of application data, which is 3*56 – 1 bytes. In other words we will need 3 blocks and 1 byte of ‘55’ padding. As such we end up with: Block1

55 61 0E 4F 01 0A 50 09 61 54 65 73 74 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 02 03 04 05 06 07 08 01 02 03 04 05 06 07 08 01 02 03 04 05 06 07

Block 2

08 01 02 03 04 05 06 07 08 3F 01 FF F3 70 00 09 03 05 6E 00 3F 01 FF F4 70 10 09 03 05 6D 00 26 21 02 28 01 5E 00 00 59 00 00 29 0E 40 06 00 40 6B C8 59 22 12 B0 49 5A

Block 3

7A D4 31 DA 01 BF 7E BE 19 0A 89 30 7E 40 D2 88 C2 00 AF D6 48 6E F6 E2 8B 0E 2E A9 69 C0 B1 46 B5 60 C4 10 C9 36 5C 00 C3 91 52 E6 06 6E EA 36 34 1F 9E 24 5C 0F 44 42

The Calculation The encipher part of the Application Hash is done using the MULTOS Cards Hash Modulus (Exponent always 3). This key may be obtained from the MULTOS KMA. For the development card used in this example the value of the key is: Public Exponent

03 Public Hash Modulus

C2 D3 75 94 54 C6 6B 0B F1 2D 5C C1 EE 3F A8 FF 9D 7E 58 4A 39 0A 12 0E 8E 40 E1 32 9D 6E 40 0E 58 F8 34 94 9D 37 F4 BD 0D 64 37 46 26 E9 72 31 F2 3E 4F 5D 31 19 9F 33 35 25 A2 44 6F AE EC 75 3B 12 B7 39 91 68 C4 99


GALU

We have an initial chain block of 16 bytes of ‘55’, which we concatenate with the first block. Initial chain block + Block1

55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 61 0E 4F 01 0A 50 09 61 54 65 73 74 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 02 03 04 05 06 07 08 01 02 03 04 05 06 07 08 01 02 03 04 05 06 07

From this the following ciphertext was generated:

22 EE 95 D6 9E 53 5F AF 57 69 35 40 7C 63 21 8E 8A DA 47 76 A7 8B 76 26 FC C4 34 8C 81 D9 11 72 CD 95 08 EE D5 34 FC EE B6 30 49 95 C9 98 87 99 CE 88 B0 C4 A8 5A 94 2F B8 CF 6F F3 26 5F B6 0D D4 8B 87 F7 3C FF DF A7

The first 16 bytes of this ciphertext will make the new chain value, BUT first we must make sure that the most significant bit (msb) is zero. In our example 22 is 00100010 which has the msb set to zero already. Let us suppose however that the first byte were 9D. This is binary 10011101 so we convert it to 00011101, which equals 1D. So our new initial value, when appended to block two, would have the first byte as 1D, not 9D. Ciphertext IV + Block 2

22 EE 95 D6 9E 53 5F AF 57 69 35 40 7C 63 21 8E 08 01 02 03 04 05 06 07 08 3F 01 FF F3 70 00 09 03 05 6E 00 3F 01 FF F4 70 10 09 03 05 6D 00 26 21 02 28 01 5E 00 00 59 00 00 29 0E 40 06 00 40 6B C8 59 22 12 B0 49 5A

This generates ciphertext:

35 82 52 3A 10 F7 F7 72 F3 07 07 7B 33 30 A3 8A BC 0E 9F C6 3B 6C 43 EE AF A7 F6 93 2C A6 BE 7E 31 65 86 62 1A C6 78 E8 21 5E 4D 3E 7A F2 2A 7C 19 4D BD B6 64 1D 94 A4 ED E8 62 DA 15 EE 59 BA A2 60 97 A8 C0 D0 B1 37

The first 16 bytes are used as the IV for the next step in the calculation. The most significant bit is already set to zero. This gives the following value. Ciphertext IV + Block 3

35 82 52 3A 10 F7 F7 72 F3 07 07 7B 33 30 A3 8A 7A D4 31 DA 01 BF 7E BE 19 0A 89 30 7E 40 D2 88 C2 00 AF D6 48 6E F6 E2 8B 0E 2E A9 69 C0 B1 46 B5 60 C4 10 C9 36 5C 00 C3 91 52 E6 06 6E EA 36 34 1F 9E 24 5C 0F 44 42




07 6A DE 39 4A 05 D9 38 8C DB 97 D2 99 90 7C BA FA A7 5B C9 76 AB 84 70 BF 87 C8 24 7B 1B 0F DF 4A B3 09 50 7D FB 70 47 21 25 10 95 DC F7 BB 39 D3 B9 17 27 E3 E8 05 82 11 D5 49 DC 6A F1 57 26 17 78 42 CF 5D 96 A2 B5

First A-Hash From this we can determine the Hash Digest of the Application Unit, from the first 16 bytes. We must also make sure that the msb is 0. So the 1st A-Hash is:

07 6A DE 39 4A 05 D9 38 8C DB 97 D2 99 90 7C BA To generate the second A-Hash we add 56 bytes of ‘55’ to the 1st A-Hash 1st A-Hash + 56 bytes ‘55’

07 6A DE 39 4A 05 D9 38 8C DB 97 D2 99 90 7C BA 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55


A2 CA C3 58 A0 A7 4F FB 4A CE 9D 2F 83 43 06 55 12 A6 2F A9 F0 24 EA AE CE 9B E4 50 D1 0A 85 79 44 1C 1F C0 DD 2A E5 23 95 99 09 75 FC E3 B8 67 5D 66 1A 13 28 B4 48 04 5C A7 98 02 6B 2E FC 96 AE 0D 6E AD E8 00 5C EF

Second A-Hash So the 2nd and actual Application Hash (having converted the most significant bit to 0) is:

22 CA C3 58 A0 A7 4F FB 4A CE 9D 2F 83 43 06 55 Pad the hash to 72 bytes to get the plaintext Application Signature


GALU

Plaintext Application Signature Note: For version 4 cards the padding are 40 bytes of 0x55 followed by 8 bytes of random data, followed by 8 bytes of ‘55’.

22 CA C3 58 A0 A7 4F FB 4A CE 9D 2F 83 43 06 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 01 02 03 04 05 06 07 08 55 55 55 55 55 55 55 55

This is then RSA enciphered using the Application Providers Private Key.

Application Provider’s Private Key The following is the Application Provider Private Key used to encrypt the plaintext Application Signature. Application Providers Private Exponent The private exponent is:

92 48 C8 E9 35 7E 1D 3A B8 4E 0B 5A 07 95 04 81 C8 38 7A 0A E1 3E 89 6D 90 3E 86 1B DA FB 44 F0 79 00 17 E7 37 42 CC 35 26 C9 04 13 42 31 D3 58 F5 69 4B CA D9 4A 0A E4 5B F6 EC 32 22 8D 9F AA E3 20 D2 F7 85 C0 BD FB

Expressed in CRT Components:

DP 9B F4 A9 1D C4 66 37 D8 70 C3 A8 F7 A6 3A C6 6C E7 57 01 DE 18 BC 2B 85 33 49 C5 EC 77 74 0D 22 12 E8 B6 A3 DQ A0 15 3F 35 45 45 28 3B 99 24 A6 FA 1D 6B 44 DC 26 0C 68 42 3E F9 62 49 32 5D D5 A6 F0 32 F3 B1 F5 63 BF 0F



P E9 EE FD AC A6 99 53 C4 A9 25 7D 73 79 58 29 A3 5B 02 82 CD 25 1A 41 47 CC EE A8 E2 B3 2E 13 B3 1C 5D 11 F5 Q F0 1F DE CF E7 E7 BC 59 65 B6 FA 77 2C 20 E7 4A 39 12 9C 63 5E 76 13 6D CB 8C C0 7A 68 4C 6D 8A F0 15 9E 97 U BB 67 A7 12 F3 11 01 2E 89 0F 53 41 23 78 AA 92 BB 65 F9 C6 27 56 57 B8 19 7E 94 CB 35 03 91 BE 01 63 68 03

Application Providers Public Modulus and Exponent The APPK modulus is:

DB 6D 2D 5D D0 3D 2B D8 14 75 11 07 0B 5F 86 C2 AC 54 B7 10 51 DD CE 24 58 5D C9 29 C8 78 E7 68 B5 80 23 DC AC F3 0E CC 48 AE 96 3A F2 27 34 F0 15 97 02 9D DA 04 2F 87 0D 82 B7 00 CC 4F D8 DD 70 2B BD B1 55 13 CD 83

The Public exponent is 3. With this key we can encipher the plaintext application signature to get the actual Application Signature.

Enciphered Application Signature The plaintext application signature once encrypted is:

27 C7 28 91 0C 2E 78 98 76 E7 AC 0D A1 45 FB 52 A6 31 C5 F0 B7 21 73 3B 3C 2E 69 C4 09 F2 59 A0 C6 0B B4 4E 34 21 58 13 8B E0 80 6D F8 34 C1 FA 17 47 40 83 68 09 8D D6 FE 1E D5 E1 26 A1 C4 98 70 AB FC FD 4C 26 4A B5


GALU

Creating the Confidential Application Load Unit The final stage is to recreate the Application Load Unit. This is a merely a case of copying the Application Unit back into the Application Load Unit and adding the Ciphertext KTU and Application Signature. Code component (unchanged)

3F 01 FF F3 70 00 09 03 05 6E 00 3F 01 FF F4 70 10 09 03 05 6D 00 26 21 02 28 01 5E 00 00 59 00 00 29 0E 40 06 00 40

Data component (enciphered)

6B C8 59 22 12 B0 49 5A 7A D4 31 DA 01 BF 7E BE 19 0A 89 30 7E 40 D2 88 C2 00 AF D6 48 6E F6 E2 8B 0E 2E A9 69 C0 B1 46 B5 60 C4 10 C9 36 5C 00 C3 91 52 E6 06 6E EA 36 34 1F 9E 24 5C 0F 44 42

DIR record entry component (unchanged)

61 0E 4F 01 0A 50 09 61 54 65 73 74 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

FCI record component (unchanged)

01 02 03 04 05 06 07 08 01 02 03 04 05 06 07 08 01 02 03 04 05 06 07 08 01 02 03 04 05 06 07 08

Application Signature component (as above)

27 C7 28 91 0C 2E 78 98 76 E7 AC 0D A1 45 FB 52 A6 31 C5 F0 B7 21 73 3B 3C 2E 69 C4 09 F2 59 A0 C6 0B B4 4E 34 21 58 13 8B E0 80 6D F8 34 C1 FA 17 47 40 83 68 09 8D D6 FE 1E D5 E1 26 A1 C4 98 70 AB FC FD 4C 26 4A B5

Ciphertext KTU component This component is enciphered with MULTOS card’s public key.

09 09 1C C6 7C BE 04 18 6A D6 B6 96 E3 8E C6 6B 18 B3 E3 B7 30 95 11 69 40 25 D5 46 E7 3E E3 39 A3 41 63 6C 2E 14 84 8A D0 A6 BE E2 0E A4 18 8E 20 EA 90 B0 EC EE 2A E4 24 D8 5E 85 E9 31 BE A7 05 4F 84 79 B0 D9 B1 07 36 0D C9 3A 2B C8 48 9A 58 24 36 A0 C6 49 7A 06 D2 8C 44 3F 68 02 EA 44



Application Load Unit The Application Load Unit once the components are combined in the correct order is as below. The Application Load Units KTU section may need to be changed to match the MCD Number of the card being used. The Load and Delete certificates will still be valid though. FE F1 80 03 FF F3 FF F1 00 27 3F 01 FF F3 70 00 09 03 05 6E 00 3F 01 FF F4 70 10 09 03 05 6D 00 26 21 02 28 01 5E 00 00 59 00 00 29 0E 40 06 00 40 00 40 6B C8 59 22 12 B0 49 5A 7A D4 31 DA 01 BF 7E BE 19 0A 89 30 7E 40 D2 88 C2 00 AF D6 48 6E F6 E2 8B 0E 2E A9 69 C0 B1 46 B5 60 C4 10 C9 36 5C 00 C3 91 52 E6 06 6E EA 36 34 1F 9E 24 5C 0F 44 42 00 20 61 0E 4F 01 0A 50 09 61 54 65 73 74 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20 01 02 03 04 05 06 07 08 01 02 03 04 05 06 07 08 01 02 03 04 05 06 07 08 01 02 03 04 05 06 07 08 00 48 27 C7 28 91 0C 2E 78 98 76 E7 AC 0D A1 45 FB 52 A6 31 C5 F0 B7 21 73 3B 3C 2E 69 C4 09 F2 59 A0 C6 0B B4 4E 34 21 58 13 8B E0 80 6D F8 34 C1 FA 17 47 40 83 68 09 8D D6 FE 1E D5 E1 26 A1 C4 98 70 AB FC FD 4C 26 4A B5 00 60 09 09 1C C6 7C BE 04 18 6A D6 B6 96 E3 8E C6 6B 18 B3 E3 B7 30 95 11 69 40 25 D5 46 E7 3E E3 39 A3 41 63 6C 2E 14 84 8A D0 A6 BE E2 0E A4 18 8E 20 EA 90 B0 EC EE 2A E4 24 D8 5E 85 E9 31 BE A7 05 4F 84 79 B0 D9 B1 07 36 0D C9 3A 2B C8 48 9A 58 24 36 A0 C6 49 7A 06 D2 8C 44 3F 68 02 EA 44

Application Load Certificate 01 22 43 11 11 11 11 11 11 11 11 01 01 01 01 00 48 00 80 00 00 01 03 00 00 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 00 00 00 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 0A 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 27 00 40 00 08 00 20 00 20 00 50 50 00 01 00 44 F9 13 21 16 8C 47 4F F7 A3 49 72 F8 D9 FC 7C DF 47 E1 6E F9 99 90 5A 0D 72 15 20 4C 0A 38 D9 06 12 89 D3 D5 0C E5 24 26 9E 68 91 14 EB C6 3A 37 D7 AB 7B FE EF 5A 04 28 1D 3A C6 59 D8 48 A2 43 C9 77 53 1B AF BB 42 D2 D8 AC 9B 01 77 C0 1B FD F5 BB 90 1D 67 F9 51 36 03 87 BF 97 51 AD 8F DA 5D 20 2F DC 17 52 2F 73 7C 75 35 31 78 5A CD 2A D1 AF AA CB 9D 5A CC 11 EE 0F 01 95 8E 1F 0F


GALU

Application Delete Certificate 01 11 44 11 11 11 11 11 11 11 11 01 01 01 01 00 48 00 80 00 00 01 03 00 00 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 00 00 00 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 0A 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 6C 1A 54 B7 1A 8B 92 95 5B 44 EA D8 AF AC D1 AD 08 BB 76 F4 EB D5 42 8C E6 C1 E9 92 83 17 D4 C0 51 CE C3 E7 AB CC FC 8D AC D8 99 56 ED E1 B9 FB 66 F4 78 89 6D BF CB 32 43 78 6C 10 0A 95 35 70 39 97 4C C6 31 E8 6F 01 D4 D8 B6 91 C5 43 8B 5B C4 C9 4B 2F 81 8A FD A1 4B 92 42 73 35 07 61 30 6A 3A 11 F0 06 73 11 15 3D 0A 22 8C 05 A5 96 6D 4B 8B 07 47 64 A5 CB CA F1 57 24 E8 65 42 80 BB

----- End of Document -----