INTERNATIONAL
`STANDARD
`
`ISO/IEC
`7816-4
`
`First edition
`1995-05-12
`
`Information technology — Identification cards
`— Integrated circuit(s) cards with contacts —
`
`Part 4 :
`Interindustry commands for interchange
`
`Technologies de l'information — Cartes d'identification — Cartes à circuit(s)
`intégré(s) à contacts —
`
`Partie 4 : Commandes intersectorielles pour les échanges
`
`Reference number
`ISO/IEC 7816-4 : 1995 (E)
`
`Samsung Ex. 1021, Page 1 of 63
`Samsung Electronics America, Inc. v. RFCyber Corp.
`IPR2021-00981
`
`

`

`ISO/IEC 7816-4 : 1995 (E)
`
`© ISO/IEC
`
`Contents
`
`Foreword ..........................................................................................................
`
`Introduction ......................................................................................................
`
`1 Scope .........................................................................................................
`
`2 Normative references ................................................................................
`
`3 Definitions ..................................................................................................
`
`4 Abbreviations and notation ........................................................................
`
`Page
`
`iii
`
`iv
`
`1
`
`1
`
`2
`
`3
`
`5 Basic organizations ....................................................................................
`5.1
`Data structures ..........................................................................................
`5.2
`Security architecture of the card ................................................................
`5.3
`APDU message structure ..........................................................................
`5.4
`Coding conventions for command headers,
`9
`data fields and response trailers ................................................................
`Logical channels ........................................................................................ 12
`Secure messaging ..................................................................................... 12
`
`5.5
`5.6
`
`3
`3
`6
`7
`
`6 Basic interindustry commands ................................................................... 16
`6.1
`READ BINARY command .............................................................................. 16
`6.2
`WRITE BINARY command ............................................................................. 17
`6.3
`UPDATE BINARY command ........................................................................... 17
`6.4
`ERASE BINARY command ............................................................................. 18
`6.5
`READ RECORD(S) command ........................................................................ 19
`6.6
`WRITE RECORD command ........................................................................... 20
`6.7
`APPEND RECORD command ......................................................................... 21
`6.8
`UPDATE RECORD command ......................................................................... 22
`6.9
`GET DATA command ................................................................................... 23
`6.10
`PUT DATA command ................................................................................... 24
`6.11
`SELECT FILE command ............................................................................... 25
`6.12
`VERIFY command ....................................................................................... 26
`6.13
`INTERNAL AUTHENTICATE command ............................................................ 27
`6.14
`EXTERNAL AUTHENTICATE command ............................................................ 27
`6.15
`GET CHALLENGE command .......................................................................... 28
`6.16
`MANAGE CHANNEL command ....................................................................... 29
`
`7 Transmission-oriented interindustry commands ....................................... 29
`7.1
`GET RESPONSE command .......................................................................... 30
`7.2
`ENVELOPE command ................................................................................. 30
`
`8 Historical bytes .......................................................................................... 31
`
`9 Application-independent card services ...................................................... 33
`
`Annexes
`
`A Transportation of APDU messages by T=0 ............................................... 35
`B Transportation of APDU messages by T=1 ............................................... 39
`C Record pointer management ..................................................................... 41
`D Use of the basic encoding rules of ASN.1 ................................................. 42
`E Examples of card profiles .......................................................................... 43
`F Use of secure messaging .......................................................................... 45
`
`© ISO/IEC 1995
`All rights reserved. No part of this publication may be reproduced or utilized in any form or
`by any means, electronic or mechanical, including photocopying and microfilm, without
`permission in writing from the publisher. ISO/IEC Copyright Office, P.O. Box 56, CH-1211
`Geneva 20, Switzerland. Printed in France
`
`ii
`
`Samsung Ex. 1021, Page 2 of 63
`Samsung Electronics America, Inc. v. RFCyber Corp.
`IPR2021-00981
`
`

`

`© ISO/IEC
`
`ISO/IEC 7816-4 : 1995 (E)
`
`Foreword
`
`ISO (the International Organization for Standardization) and IEC (the International
`Electrotechnical Commission)
`together
`form a system
`for worldwide
`standardization as a whole. National bodies that are members of ISO or IEC
`participate in the development of International Standards through technical
`committees established by the respective organization to deal with particular
`fields of technical activity. ISO and IEC technical committees collaborate in fields
`of mutual interest. Other international organizations, governmental and non-
`governmental, in liaison with ISO and IEC, also take part in the work.
`
`In the field of information technology, ISO and IEC have established a joint
`technical committee, ISO/IEC JTC1. Draft International Standards adopted by the
`joint technical committee are circulated to the national bodies for voting.
`Publication as an International Standard requires at least 75 % approval by the
`national bodies casting a vote.
`
`ISO/IEC 7816-4 was prepared by Joint Technical
`International Standard
`Committee ISO/IEC JTC1, Information Technology.
`
`Annexes A and B form an integral part of this part of ISO/IEC 7816.
`
`Annexes C, D, E and F are for information only.
`
`ISO/IEC 7816 is a multi-part standard, under the general title of, Information
`technology — Identification cards — Integrated circuit(s) cards with contacts.
`— Part 1 : Physical characteristics,
`— Part 2 : Dimensions and location of the contacts,
`— Part 3 : Electronic signals and transmission protocols,
`— Part 4 : Interindustry commands for interchange,
`— Part 5 : Numbering system and registration procedure for application
`identifiers,
`— Part 6 : Interindustry data elements.
`
`iii
`
`Samsung Ex. 1021, Page 3 of 63
`Samsung Electronics America, Inc. v. RFCyber Corp.
`IPR2021-00981
`
`

`

`ISO/IEC 7816-4 : 1995 (E)
`
`© ISO/IEC
`
`Introduction
`
`This part of ISO/IEC 7816 is one of a series of standards describing the
`parameters for integrated circuit(s) cards with contacts and the use of such cards
`for international interchange.
`
`These cards are identification cards intended for information exchange negotiated
`between the outside and the integrated circuit in the card. As a result of an
`information exchange, the card delivers information (computation results, stored
`data), and/or modifies its content (data storage, event memorization).
`
`iv
`
`Samsung Ex. 1021, Page 4 of 63
`Samsung Electronics America, Inc. v. RFCyber Corp.
`IPR2021-00981
`
`

`

`© ISO/IEC
`
`ISO/IEC 7816-4 : 1995 (E)
`
`Information technology —
`Identification cards
`— Integrated circuit(s)
`cards with contacts —
`
`ISO/IEC 7812-1 : 1993, Identification cards — Issuer iden-
`tification — Part 1 : Numbering system.
`
`ISO/IEC 7816-3 : 1989, Identification cards — Integrated
`circuit(s) cards with contacts — Part 3 : Electronic signals
`and transmission protocols.
`
`Amendment 1 : 1992 to ISO/IEC 7816-3 : 1989, Protocol
`type T=1, asynchronous half duplex block transmission
`protocol.
`
`Amendment 2 : 1994 to ISO/IEC 7816-3 : 1989, Revision of
`protocol type selection.
`
`for
`
`ISO/IEC 7816-5 : 1994, Identification cards — Integrated
`circuit(s) cards with contacts — Part 5 : Numbering system
`and registration procedure for application identifiers.
`
`Part 4 :
`Interindustry commands
`interchange
`
`1 Scope
`
`This part of ISO/IEC 7816 specifies
`— the content of the messages, commands and res-
`ponses, transmitted by the interface device to the card
`and conversely,
`— the structure and content of the historical bytes sent
`by the card during the answer to reset,
`— the structure of files and data, as seen at the
`interface when processing interindustry commands for
`interchange,
`— access methods to files and data in the card,
`— a security architecture defining access rights to files
`and data in the card,
`— methods for secure messaging,
`— access methods to the algorithms processed by the
`card. It does not describe these algorithms.
`
`It does not cover the internal implementation within the card
`and/or the outside world.
`
`It allows further standardization of additional interindustry
`commands and security architectures.
`
`2 Normative references
`
`The following standards contain provisions which, through
`reference in this text, constitute provisions of this part of
`ISO/IEC 7816. At the time of publication, the editions
`indicated were valid. All standards are subject to revision,
`and parties
`to agreements based on
`this part of
`ISO/IEC 7816 are encouraged to investigate the possibility
`of applying the most recent editions of the standards
`indicated below. Members of
`IEC and
`ISO maintain
`registers of currently valid International Standards.
`
`ISO 3166 : 1993, Codes for the representation of names of
`countries.
`
`5
`
`ISO/IEC 7816-6 : 199X, Identification cards — Integrated
`circuit(s) cards with contacts — Part 6 : Interindustry data
`elements.
`
`technology — Open
`Information
`ISO/IEC 8825 : 1990,
`systems interconnection — Specification of basic encoding
`rules for abstract syntax notation one (ASN.1).
`
`ISO/IEC 9796 : 1991, Information technology — Security
`techniques — Digital signature scheme giving message
`recovery.
`
`ISO/IEC 9797 : 1993, Information technology — Security
`techniques — Data integrity mechanisms using a crypto-
`graphic check function employing a block cipher algorithm.
`
`techniques —
`Cryptographic
`ISO/IEC 9979 : 1991,
`Procedures for the registration of cryptographic algorithms.
`
`technology —
`Information
`ISO/IEC 10116 : 1991,
`Information technology — Security techniques — Modes of
`operation of an n-bit block cipher algorithm.
`
`ISO/IEC 10118-1 : 1994, Information technology — Security
`techniques — Hash functions — Part 1 : General.
`
`ISO/IEC 10118-2 : 1994, Information technology — Security
`techniques — Hash functions — Part 2 : Hash functions
`using an n-bit block cipher algorithm.
`
`3 Definitions
`
`For the purpose of this part of ISO/IEC 7816, the following
`definitions apply.
`
`Answer-to-Reset file : Elementary
`3.1
`indicates operating characteristics of the card.
`
`file which
`
`command-response pair : Set of two messages : a
`3.2
`command followed by a response.
`
`data unit : The smallest set of bits which can be
`3.3
`unambiguously referenced.
`
`Samsung Ex. 1021, Page 5 of 63
`Samsung Electronics America, Inc. v. RFCyber Corp.
`IPR2021-00981
`
`

`

`ISO/IEC 7816-4 : 1995 (E)
`
`© ISO/IEC
`
`data element : Item of information seen at the
`3.4
`interface for which are defined a name, a description of
`logical content, a format and a coding.
`
`record number : Sequential number assigned to
`3.22
`each record which uniquely identifies the record within its
`elementary file.
`
`data object : Information seen at the interface which
`3.5
`consists of a tag, a length and a value (i.e., a data element).
`In this part of ISO/IEC 7816, data objects are referred to as
`BER-TLV, COMPACT-TLV and SIMPLE-TLV data objects.
`3.6
`dedicated file : File containing file control infor-
`mation and, optionally, memory available for allocation. It
`may be the parent of EFs and/or DFs.
`
`DF name : String of bytes which uniquely identifies a
`3.7
`dedicated file in the card.
`
`directory file : Elementary file defined in part 5 of
`3.8
`ISO/IEC 7816.
`
`elementary file : Set of data units or records which
`3.9
`share the same file identifier. It cannot be the parent of
`another file.
`
`file control parameters : Logical, structural and
`3.10
`security attributes of a file.
`
`file identifier : A 2-bytes binary value used
`3.11
`address a file.
`
`to
`
`file management data : Any information about a file
`3.12
`except the file control parameters (e.g., expiration date,
`application label).
`
`internal elementary file : Elementary file for storing
`3.13
`data interpreted by the card.
`
`3.14 master file : The mandatory unique dedicated file
`representing the root of the file structure.
`
`the
`transmitted by
`3.15 message : String of bytes
`interface device
`to
`the card or vice-versa, excluding
`transmission-oriented characters as defined in part 3 of
`ISO/IEC 7816.
`
`3.16 parent file : The dedicated file immediately pre-
`ceding a given file within the hierarchy.
`
`3.17 password : Data which may be required by the
`application to be presented to the card by its user.
`
`identifiers without
`file
`3.18 path : Concatenation of
`delimitation. If the path starts with the identifier of the
`master file, it is an absolute path.
`
`3.23 working elementary file : Elementary file for storing
`data not interpreted by the card.
`
`4 Abbreviations and notation
`
`For the purpose of this part of ISO/IEC 7816, the following
`abbreviations apply.
`APDU
`Application protocol data unit
`ATR
`Answer to reset
`BER
`Basic encoding rules of ASN.1 (see annex D)
`CLA
`Class byte
`DIR
`Directory
`DF
`Dedicated file
`EF
`Elementary file
`FCI
`File control information
`FCP
`File control parameter
`FMD
`File management data
`INS
`Instruction byte
`MF
`Master file
`P1-P2
`Parameter bytes
`PTS
`Protocol type selection
`RFU
`Reserved for future use
`SM
`Secure messaging
`SW1-SW2 Status bytes
`TLV
`Tag, length, value
`TPDU
`Transmission protocol data unit
`
`For the purpose of this part of ISO/IEC 7816, the following
`notation applies.
`The sixteen hexadecimal digits
`'0' to '9' and 'A' to 'F'
`(B1)
`Value of byte B1
`B1 || B2
`Concatenation of bytes B1 (the most significant
`byte) and B2 (the least significant byte)
`(B1 || B2) Value of the concatenation of bytes B1 and B2
`#
`Number
`
`5 Basic organizations
`
`3.19 provider : Authority who has or who obtained the
`right to create a dedicated file in the card.
`
`5.1 Data structures
`
`record : String of bytes which can be handled as a
`3.20
`whole by the card and referenced by a record number or by
`a record identifier.
`
`record identifier : Value associated with a record
`3.21
`that can be used to reference that record. Several records
`may have the same identifier within an elementary file.
`
`This clause contains information on the logical structure of
`data as seen at the interface, when processing interindustry
`commands for interchange. The actual storage location of
`data and structural information beyond what is described in
`this clause are outside the scope of ISO/IEC 7816.
`
`6
`
`Samsung Ex. 1021, Page 6 of 63
`Samsung Electronics America, Inc. v. RFCyber Corp.
`IPR2021-00981
`
`

`

`© ISO/IEC
`
`5.1.1
`
`File organization
`
`This part of ISO/IEC 7816 supports the following two cate-
`gories of files.
`— Dedicated file (DF).
`— Elementary file (EF).
`
`The logical organization of data in a card consists of the
`following structural hierarchy of dedicated files.
`— The DF at the root is called the master file (MF). The
`MF is mandatory.
`— The other DFs are optional.
`
`The following two types of EFs are defined.
`— Internal EF — Those EFs are intended for storing
`data interpreted by the card, i.e., data analyzed and
`used by
`the card
`for management and control
`purposes.
`— Working EF — Those EFs are intended for storing
`data not interpreted by the card, i.e., data to be used by
`the outside world exclusively.
`
`illustrates an example of
`Figure 1
`organization in a card.
`
`the
`
`logical
`
`file
`
`EF
`
`EF
`
`DF
`
`MF
`
`EF
`
`EF
`
`DF
`
`EF
`
`DF
`
`EF
`
`EF
`
`DF
`
`Figure 1 — Logical file organization (example)
`
`5.1.2
`
`File referencing methods
`
`When a file cannot be implicitly selected, it shall be possible
`to select it by at least one of the following methods.
`
`ref-
`file may be
`— Referencing by file identifier — Any
`erenced by a file identifier coded on 2 bytes. If the MF is
`referenced by a file identifier, '3F00' shall be used (reserved
`value). The value 'FFFF' is reserved for future use. The
`value '3FFF' is reserved (see referencing by path). In order
`to select unambiguously any file by its identifier, all EFs and
`DFs immediately under a given DF shall have different file
`identifiers.
`
`— Referencing by path — Any file may be referenced by a
`path (concatenation of file identifiers). The path begins with
`the identifier of the MF or of the current DF and ends with
`the identifier of the file itself. Between those two identifiers,
`the path consists of the identifiers of the successive parent
`DFs if any. The order of the file identifiers is always in the
`direction parent to child. If the identifier of the current DF is
`not known, the value '3FFF' (reserved value) can be used at
`the beginning of the path. The path allows an unambiguous
`selection of any file from the MF or from the current DF.
`
`7
`
`ISO/IEC 7816-4 : 1995 (E)
`
`— Referencing by short EF identifier — Any EF may be
`referenced by a short EF identifier coded on 5 bits valued in
`the range from 1 to 30. The value 0 used as a short EF
`identifier references the currently selected EF. Short EF
`identifiers cannot be used in a path or as a file identifier
`(e.g., in a SELECT FILE command).
`
`— Referencing by DF name — Any DF may be referenced
`by a DF name coded on 1 to 16 bytes. In order to select
`unambiguously by DF name (e.g., when selecting by means
`of application
`identifiers as defined
`in part 5 of
`ISO/IEC 7816), each DF name shall be unique within a
`given card.
`
`5.1.3
`
`Elementary file structures
`
`The following structures of EFs are defined.
`— Transparent structure — The EF
`is seen at
`interface as a sequence of data units.
`— Record structure — The EF is seen at the interface
`as a sequence of individually identifiable records.
`
`the
`
`The following attributes are defined for EFs structured in
`records.
`— Size of the records : either fixed or variable.
`— Organization of the records : either as a sequence
`(linear structure) or as a ring (cyclic structure).
`
`The card shall support at least one of the following four
`methods for structuring EFs.
`— Transparent EF.
`— Linear EF with records of fixed size.
`— Linear file with records of variable size.
`— Cyclic EF with records of fixed size.
`
`Figure 2 shows those four EF structures.
`
`Transparent
`
`Linear fixed
`
`Linear variable
`
`Cyclic fixed
`
`••••••
`
`••••••
`
`Figure 2 — EF structures
`
`NOTE — The arrow on the figure references the most recently
`written record.
`
`5.1.4
`
`Data referencing methods
`
`Data may be referenced as records, as data units or as
`data objects. Data is considered to be stored in a single
`continuous sequence of records (within an EF of record
`structure) or of data units (within an EF of transparent
`structure). Reference to a record or to a data unit outside an
`EF is an error.
`
`Data referencing method, record numbering method and
`data unit size are EF-dependent features. The card can
`provide indications in the ATR, in the ATR file and in any file
`control information. When the card provides indications in
`
`Samsung Ex. 1021, Page 7 of 63
`Samsung Electronics America, Inc. v. RFCyber Corp.
`IPR2021-00981
`
`

`

`ISO/IEC 7816-4 : 1995 (E)
`
`© ISO/IEC
`
`several places, the indication valid for a given EF is the
`closest one to that EF within the path from the MF to that
`EF.
`
`— Referencing by record number — Within each EF of
`record structure, the record numbers are unique and
`sequential.
`
`5.1.4.1
`
`Record referencing
`
`Within each EF of record structure, each record can be
`referenced by a record identifier and/or by a record number.
`Record identifiers and record numbers are unsigned 8-bit
`integers with values in the range from '01' to 'FE'. The value
`'00' is reserved for special purposes. The value 'FF' is RFU.
`
`Referencing by record identifier shall induce the man-
`agement of a record pointer. A reset of the card, a
`SELECT FILE and any command carrying a valid short EF
`identifier can affect the record pointer. Referencing by
`record number shall not affect the record pointer.
`
`— Referencing by record identifier — Each record identifier
`is provided by an application. If a record is a SIMPLE-TLV data
`object in the data field of a message (see 5.4.4), then the
`record identifier is the first byte of the data object. Within an
`EF of record structure, records may have the same record
`identifier, in which case data contained in the records may
`be used for discriminating between them.
`
`Each time a reference is made with a record identifier, an
`indication shall specify the logical position of the target
`record : the first or last occurrence, the next or previous
`occurrence relative to the record pointer.
`
`— Within each EF of linear structure, the logical posi-
`tions shall be sequentially assigned when writing or
`appending, i.e., in the order of creation. Therefore the
`first created record is in the first logical position.
`
`— Within each EF of cyclic structure, the logical posi-
`tions shall be sequentially assigned in the opposite
`order, i.e., the most recently created record is in the
`first logical position.
`
`The following additional rules are defined for linear struc-
`tures and for cyclic structures.
`
`— The first occurrence shall be the record with the
`specified identifier and in the first logical position ; the
`last occurrence shall be the record with the specified
`identifier and in the last logical position.
`
`— When there is no current record, the next occurrence
`shall be equivalent to the first occurrence ; the previous
`occurrence shall be equivalent to the last occurrence.
`
`— When there is a current record, the next occurrence
`shall be the closest record with the specified identifier
`but in a greater logical position than the current record ;
`the previous occurrence shall be the closest record with
`the specified identifier but in a smaller logical position
`than the current record.
`
`— The value '00' shall refer to the first, last, next or
`previous record in the numbering sequence, indepen-
`dently from the record identifier.
`
`8
`
`— Within each EF of linear structure, the record num-
`bers shall be sequentially assigned when writing or
`appending, i.e., in the order of creation. Therefore the
`first record (record number one, # 1) is the first created
`record.
`
`— Within each EF of cyclic structure, the record num-
`bers shall be sequentially assigned in the opposite
`order, i.e., the first record (record number one, # 1) is
`the most recently created record.
`
`The following additional rule is defined for linear structures
`and for cyclic structures.
`
`— The value '00' shall refer to the current record, i.e.,
`that record fixed by the record pointer.
`
`5.1.4.2
`
`Data unit referencing
`
`Within each EF of transparent structure, each data unit can
`be referenced by an offset (e.g., in READ BINARY command,
`see 6.1). It is an unsigned integer, limited to either 8 or 15
`bits according to an option in the respective command.
`Valued to 0 for the first data unit of the EF, the offset is
`incremented by 1 for every subsequent data unit.
`
`By default, i.e., if the card gives no indication, the size of the
`data unit is one byte.
`
`NOTES
`
`An EF of record structure may support data unit referencing
`1
`and, in case it does, data units may contain structural information
`along with data, e.g., record numbers in a linear structure.
`
`2 Within an EF of record structure, data unit referencing may not
`provide the intended result because the storage order of the
`records in the EF is not known, e.g., storage order in a cyclic
`structure.
`
`5.1.4.3
`
`Data object referencing
`
`Each data object (as defined in 5.4.4) is headed by a tag
`which references it. Tags are specified in this part and other
`parts of ISO/IEC 7816.
`
`5.1.5
`
`File control information
`
`The file control information (FCI) is the string of data bytes
`available in response to a SELECT FILE command. The file
`control information may be present for any file.
`
`Table 1 introduces 3 templates intended for conveying file
`control information when coded as BER-TLV data objects.
`— The FCP template is intended for conveying file
`control parameters (FCP), i.e., any BER-TLV data objects
`defined in table 2.
`
`Samsung Ex. 1021, Page 8 of 63
`Samsung Electronics America, Inc. v. RFCyber Corp.
`IPR2021-00981
`
`

`

`L
`2
`
`2
`
`1
`
`2
`
`3 or 4
`
`Value
`Number of data bytes
`in the file, excluding structural
`information
`Number of data bytes
`in the file, including
`structural information if any
`File descriptor byte
`(see table 3)
`File descriptor byte followed
`by data coding byte
`(see table 86)
`File descriptor byte followed
`by data coding byte and
`maximum record length
`File identifier
`2
`1 to 16 DF name
`var.
`Proprietary information
`var.
`Security attributes
`(coding outside the scope
`of this part of ISO/IEC 7816)
`Identifier of an EF containing
`an extension of the FCI
`RFU
`
`2
`
`RFU
`
`Applies to
`Transparen
`t EFs
`
`Any file
`
`Any file
`
`Any file
`
`EFs with
`record
`structure
`Any file
`DFs
`Any file
`Any file
`
`Any file
`
`© ISO/IEC
`
`ISO/IEC 7816-4 : 1995 (E)
`
`Table 2 — File control parameters
`
`— The FMD template is intended for conveying file
`management data (FMD), i.e., BER-TLV data objects
`specified in other clauses of this part or in other parts of
`ISO/IEC 7816 (e.g., application label as defined in part
`5 and application expiration date as defined in part 6).
`— The FCI template is intended for conveying file
`control parameters and file management data.
`
`Table 1 — Templates relevant to FCI
`
`Tag
`'62'
`'64'
`'6F'
`
`Value
`File control parameters (FCP template)
`File management data (FMD template)
`File control information (FCI template)
`
`The 3 templates may be retrieved according to selection
`options of the SELECT FILE command (see table 59). If the
`FCP or FMD option is set, then the use of the corre-
`sponding template is mandatory. If the FCI option is set,
`then the use of the FCI template is optional.
`
`Part of the file control information may additionally be
`present in a working EF under control of an application and
`referenced under tag '87'. The use of the FCP or FCI
`template
`is mandatory
`for
`the coding of
`file control
`information in such an EF.
`
`File control information not coded according to this part of
`ISO/IEC 7816 may be introduced as follows.
`— '00' or any value higher than '9F' — The coding of
`the subsequent string of bytes is proprietary.
`— Tag = '53' — The value field of the data object
`consists of discretionary data not coded in TLV.
`— Tag = '73' — The value field of the data object
`consists of discretionary BER-TLV data objects.
`
`Tag
`'80'
`
`'81'
`
`'82'
`
`'83'
`'84'
`'85'
`'86'
`
`'87'
`
`'88' to
`'9E'
`'9FXY'
`
`9
`
`Samsung Ex. 1021, Page 9 of 63
`Samsung Electronics America, Inc. v. RFCyber Corp.
`IPR2021-00981
`
`

`

`ISO/IEC 7816-4 : 1995 (E)
`
`© ISO/IEC
`
`Table 3 — File descriptor byte
`
`b8 b7 b6 b5 b4 b3 b2 b1
`
`Meaning
`
`— by secure messaging (e.g., message authenti-
`cation).
`
` 0 x
` 0 0
` 0 1
`
` 0
` 0
` 0
` 0
` 0
` 0
` 0
` 0
` 0
`
` 0
` 0
` 0
` 0
` 0
` 0
` 0
` 0
` 0
`
`-
`-
`-
`-
`-
`-
`-
`-
`-
`
`-
`-
`-
`-
`-
`-
`-
`-
`-
`
`-
`-
`-
`
`x
`0
`0
`0
`0
`1
`1
`1
`1
`
`-
`-
`-
`-
`-
`-
`-
`-
`-
`
`-
`-
`-
`
`x
`0
`0
`1
`1
`0
`0
`1
`1
`
`-
`-
`-
`-
`-
`-
`-
`-
`-
`
`-
`-
`-
`
`x
`0
`1
`0
`1
`0
`1
`0
`1
`
`-
`-
`-
`-
`-
`-
`-
`-
`-
`
` 1 x
`
`x
`
`x
`
`x
`
`-
`-
`-
`
`-
`-
`-
`-
`-
`-
`-
`-
`-
`
`x
`0
`0
`0
`0
`1
`1
`1
`1
`
`x
`
`-
`-
`-
`
`-
`-
`-
`-
`-
`-
`-
`-
`-
`
`x
`0
`0
`1
`1
`0
`0
`1
`1
`
`x
`
`File accessibility
`-
`- — Not shareable file
`- — Shareable file
`
`File type
`-
`- — Working EF
`- — Internal EF
`- — Reserved
`-
` for
`-
` proprietary
`-
` types
`-
` of EFs
`- — DF
`
`EF structure
`x
`0 — No information given
`1 — Transparent
`0 — Linear fixed, no further info
`1 — Linear fixed, SIMPLE-TLV
`0 — Linear variable, no further info
`1 — Linear variable, SIMPLE-TLV
`0 — Cyclic, no further info
`1 — Cyclic, SIMPLE-TLV
`
`x
`
`RFU
`
`"Shareable" means that the file supports at least concurrent
`access on different logical channels.
`
`5.2 Security architecture of the card
`
`This clause describes the following features :
`— security status,
`— security attributes,
`— security mechanisms.
`
`Security attributes are compared with the security status to
`execute commands and/or to access files.
`
`5.2.1 Security status
`
`the current state possibly
`
`Security status represents
`achieved after completion of
`— answer to reset (ATR) and possible protocol type
`selection (PTS) and/or
`— a single command or a sequence of commands,
`possibly performing authentication procedures.
`
`The security status may also result from the completion of a
`security procedure related to the identification of the
`involved entities, if any, e.g.,
`— by proving the knowledge of a password (e.g., using
`a VERIFY command),
`— by proving the knowledge of a key (e.g., using a
`GET CHALLENGE
`command
`followed
`by
`an
`EXTERNAL AUTHENTICATE command).
`
`10
`
`Three security statuses are considered.
`
`— Global security status — It may be modified by the
`completion of an MF-related authentication procedure
`(e.g., entity authentication by a password or by a key
`attached to the MF).
`
`— File-specific security status — It may be modified by
`the completion of a DF-related authentication pro-
`cedure (e.g., entity authentication by a password or by
`a key attached to the specific DF) ; it may be main-
`tained, recovered or lost by file selection (see 6.10.2) ;
`this modification may be relevant only for the applica-
`tion to which the authentication procedure belongs.
`
`— Command-specific security status — It only exists
`during the execution of a command involving authen-
`tication using secure messaging (see 5.6) ; such a
`command may
`leave
`the other security status
`unchanged.
`
`If the concept of logical channels is applied, the file specific
`security status may depend on the logical channel (see
`5.5.1).
`
`5.2.2
`
`Security attributes
`
`The security attributes, when they exist, define the allowed
`actions and the procedures to be performed to complete
`such actions.
`
`Security attributes may be associated with each file and fix
`the security conditions that shall be satisfied to allow
`operations on the file. The security attributes of a file
`depend on
`
`— its category (DF or EF),
`
`— optional parameters in its file control information
`and/or in that of its parent file(s).
`
`NOTE — Security attributes may also be associated to other
`objects (e.g., keys).
`
`5.2.3
`
`Security mechanisms
`
`This part of ISO/IEC 7816 defines the following security
`mechanisms.
`
`— Entity authentication with password — The card
`compares data received from the outside world with
`secret internal data. This mechanism may be used for
`protecting the rights of the user.
`
`— Entity authentication with key — The entity to be
`authenticated has to prove the knowledge of the
`relevant key in an authentication procedure (e.g., using
`a
`GET CHALLENGE
`command
`followed
`by
`an
`EXTERNAL AUTHENTICATE command).
`
`Samsung Ex. 1021, Page 10 of 63
`Samsung Electronics America, Inc. v. RFCyber Corp.
`IPR2021-00981
`
`

`

`© ISO/IEC
`
`ISO/IEC 7816-4 : 1995 (E)
`
`— Data authentication — Using internal data, either
`secret or public, the card checks redundant data
`received from the outside world. Alternately, using
`secret internal data, the card computes a data element
`(cryptographic checksum or digital signature) and
`inserts it in the data sent to the outside world. This
`mechanism may be used for protecting the rights of a
`provider.
`
`— Data encipherment — Using secret internal data, the
`card deciphers a cryptogram received in a data field.
`Alternately, using internal data, either secret or public,
`the card computes a cryptogram and inserts it in a data
`field, possibly together with other data. This mechanism
`may be used to provide a confidentiality service, e.g.,
`for key management and conditional access. In addition
`to the cryptogram mechanism, data confidentiality can
`be achieved by data concealment. In this case, the card
`computes a string of concealing bytes and adds it by
`exclusive-or to data bytes received from or sent to the
`outside world. This mechanism may be used for
`protecting privacy and for reducing the possibilities of
`message filtering.
`
`The number of bytes present in the data field of the
`command APDU is denoted by Lc.
`
`The maximum number of bytes expect