Apdu Commands Create File

Interindustry Smart Card Commands (ISO 7816-4) As was mentioned previously, in an effort to provide some standardizationamong smart cards, an interindustry command set was defined in the ISO/IEC7816-4 specification. This command set included commands in two distinct areas,as well as several general-purpose, administrative commands. The two specificareas are: • security features • on-card file systems The commands aimed at security provide mechanisms that allow theauthentication of identity among the participants in smart card–basedtransactions. That is, computers can authenticate to computers and a person (acardholder) can authenticate to a computer (the smart card).

A contactless smart card is a contactless credential whose dimensions are credit-card size. Its embedded integrated circuits can store (and sometimes process) data. Type 4 Tag Operation Specification. Technical Specification.

These mechanismsare based in well-established cryptographic operations. APDUs The messages used to support the ISO 7816-4–defined applicationprotocol(s) comprise two structures: one used by the reader side of the channelto send commands to the card and the other used by the card to send responsesback to the reader.

The former is referred to as the command APDU and thelatter as the response APDU. As illustrated in, the command APDU comprises a header anda body, each of which is further subdivided into several fields.

Theheader includes CLA, INS, P1, and P2 fields. CLA and INS define an applicationclass and instruction group as described, for example, in ISO 7816-4. The P1 andP2 fields are used to qualify specific instructions and are therefore givenspecific definitions by each [CLA,INS] instruction. The body of the APDUis a variable size (and form) component that is used to convey information tothe card's APDU processor as part of a command or to convey informationfrom the card back to the reader as part of a response to a command. The Lcfield specifies the number of bytes to be transferred to the card as part of aninstruction; it contains the length of the data field. The data field comprisesdata that must be conveyed to the card in order to allow its APDU processor toexecute the command specified in the APDU.

The Le field specifies the number ofbytes that will be returned to the reader by the card's APDU processor inthe response APDU for this particular command. The body of the APDU can havefour different forms: Command APDU structure. • No data is transferred to or from the card, so the APDU includes only theheader component. • No data is transferred to the card but data is returned from the card, sothe body of the APDU includes only a non-null Le field. • Data is transferred to the card but no data is returned from the card asa result of the command, so the body of the APDU includes the Lc field and thedata field. • Data is transferred to the card and data is returned from the card as aresult of the command, so the body of the APDU includes the Lc field, the datafield, and the Le field.

Illustrates the much simpler structure of the response APDUstructure. It includes a body and a trailer. The body is either null or includesa data field, depending on the specific command that it is a response to anddepending on whether that command was successfully executed by the card'sAPDU processor. If the response APDU does include a data field, its length isdetermined by the Le field of the command to which the response corresponds. Response APDU structure. Error Responses The response APDU also includes a trailer field, which can comprise twofields of status information that are referenced as SW1 and SW2. These fieldsreturn (from the card's APDU processor) to the reader-side application astatus code that, according to ISO 7816-4, has a numbering scheme in which onebyte is used to convey an error category and the other byte is used to convey acommand-specific status or error indication.

This numbering scheme isillustrated in. ISO/IEC 7816-4 return codes. The CLA code that is included in each command APDU has two additionalcomponents to be noted: • The two low-order bits of the CLA byte can be used to designate a logicalcommunication channel between the reader-side application and the card'sAPDU processor. • The next two higher order bits of the CLA byte can be used to indicatethat secure messaging is to be used between the reader-side application and thecard's APDU processor.

After the link-level protocol is established between the reader-sideapplication and the card's APDU processor, a base-level (command) logicalchannel is created. This is indicated (in the CLA byte) by both of the low-orderbits being 0. Additional logical channels can be created by using the ManageChannel command, which is defined by ISO 7816-4. ISO 7816-4 also defines a modest secure messaging protocol, which can be usedto ensure privacy and integrity of APDUs transferred between the reader-sideapplication and the card's APDU processor.

Security Commands Associated with each component of the file system is a list of accessproperties. Through these access properties, a state can be defined such thatthe smart card system must be put into that state, through the successfulexecution of a series of commands by the reader, before that component of thefile system can be accessed. At the most basic level, the operations to beperformed on the file system are to select a specific file and then writeinformation to that file or read information from that file. As shown in thefollowing sections, the access properties may be as simple as requiring thereader to provide a predefined PIN or as complex as the reader proving that itpossesses some shared secret (e.g., a key) with the card. These mechanisms willbe reviewed in more detail in the following sections. The Verify Command CLA INS P1 P2 Lc Data C0 16 20 16 00 16 00 16 03 16 53 16 61 16 53 16 The Verify command is a command sent by a reader-sideapplication to the security system on the card to allow it to check for a matchto password type information stored on the card.

This command is used to allowthe reader-side application to convince the card that it (the reader-sideapplication) knows a password maintained by the card to restrict access toinformation on the card. The password type information may be attached to a specific file on the cardor to part or all of the file hierarchy on the card. Successful execution ofthis command indicates that the reader-side application did know the correctpassword and it puts the card into a state such that a subsequent access to afile guarded by this password information will succeed. If the Verify command fails (i.e., the password required by the cardis not correctly provided by the reader-side application), then an error statusindicator is returned by the card to the reader-side application. The Internal Authenticate Command CLA INS P1 P2 Lc Data C0 16 88 16 00 16 00 16 03 16 02 16 01 16 03 16 The Internal Authenticate command is a command sent by areader-side application to the security system on the card to allow the card toprove that it possesses a secret key that is shared with the reader-sideapplication. To prepare this command, the reader-side application creates a setof challenge data (i.e., essentially, the reader-side application generates arandom number). This number is then encrypted with some agreed-on algorithm(with the card); this constitutes a challenge to the card.

When given the command, the card then decrypts the challenge with a secretkey stored in a file on the card. The information derived from the decryption isthen passed back to the reader-side application as a response to the command. Ifthe card really does have the correct secret key, then the information passedback will be the random number generated by the reader-side application prior toissuing the Internal Authenticate command. This command is used by the reader-side application to authenticate thecard's identity.

That is, when successfully completed, the reader-sideapplication knows the identity of the card and can give to the card access toinformation or services within the reader-side application. The External Authenticate Command CLA INS P1 P2 Lc Data C0 16 82 16 00 16 00 16 03 16 03 16 02 16 01 16 03 16 The External Authenticate command is used by areader-side application, in conjunction with the Get Challenge command(described in the next section) to allow the reader-side application toauthenticate its identity to the card. Through the Get Challenge command, the reader-side applicationreceives a set of challenge data from the card (i.e., a random number generatedby the card). The reader-side application then encrypts this information with asecret key. This then forms a challenge, which is sent to the card via the External Authenticate command.

If the reader-side application knows thesame secret key that is stored on the card, then when the card decrypts thechallenge, it will find the same random number generated by the last GetChallenge command. Therefore, the card now knows the identity of thereader-side application and can give it (the reader-side application) to data onthe card. The attractive characteristic of this method (from a security standpoint) isthat the secret key used to authenticate identity between the reader-sideapplication and the card was never transferred between the reader-sideapplication and the card. The Get Challenge Command CLA INS P1 P2 Lc Data C0 16 84 16 00 16 00 16 06 16 empty The Get Challenge command is used by the reader-sideapplication to extract information that can be used to formulate a challenge tothe card that can be validated through an External Authenticate command.The result of this command is the generation of a random number by the card,which is then passed back to the reader-side application.

File System A central application for smart cards defined by the ISO/IEC 7816-4 standardis a file system. The file system is actually applied to the nonvolatile memoryon the smart card, generally electrically erasable and programmable read-onlymemory (EEPROM). The file system defined is a relatively straightforwardhierarchical structure comprising three basic elements: • a master file (MF) component • a directory file (DF) component • an elementary file (EF) component The MF component is the root of the file hierarchy; there is only one MF on asmart card. An MF may contain as elements a DF, or even many DFs, and it maycontain none to many EFs. The DF component is essentially a container for EFcomponents; a DF may contain none to many EFs. An EF component may contain onlyrecords. This simple hierarchical structure is illustrated in.

The smart card file system architecture. Several characteristics of the smart card file system are significantlydifferent from typical (e.g., disk-based) file systems. These differences arealmost exclusively due to the physical characteristics of the EEPROM memorysystem—specifically, the facts that EEPROM memory can only be subjected toa modest number of erase and write cycles and that it is significantly faster towrite to EEPROM memory in a cumulative fashion than in a pure erase and thenwrite fashion. The first of these characteristics resulted in the definition ofa rather unique file structure called a cyclic file. The secondcharacteristic resulted in rather unique definitions of the various file writecommands. The cyclic file is actually a ring buffer of physical files that areaddressed and accessed as a single file. On successive write operations, thenext physical file (in the ring of physical files) is accessed.

The net resultis that erase and write operations can be spread across a wider selection ofEEPROM memory locations. Fleetwood Terry Trailer Owners Manual. This mitigates somewhat the limit (generally on theorder of 100,000 cycles) on the number of times that a specific EEPROM memorylocation can be erased and rewritten. EEPROM memory has the additional interesting characteristic that it issignificantly faster to set additional bits in a memory location than it is toerase all the currently set bits and then rewrite them. This fact becomes doublyuseful in certain operations (e.g., manipulating a purse value on a smart card)where it is required that operations on a file be performed in such a fashionthat the values stored in the file are well understood at any point in time,even if power is removed from the smart card in the middle of a file operation.To facilitate the exploitation of these characteristics, the write operations toa smart card file are typically bit-set operations while the update operationsare actually erase and rewrite operations, which we generally associate withfile-writing operations. These characteristics will be examined in a bit moredetail in the following sections. MF Characteristics Each smart card file system has exactly one MF. The MF serves as the root ofthe hierarchical file structure.

In the parlance of general file systems, the MFis a container or a directory; it may contain other dedicated (or directory)files (DFs) or it may contain EFs. Any file can be identified by a 2-byte file identifier. The file identifier 3F00 is reserved for the MF; that is, there is only one file with a fileidentifier of 3F00, and the file with that identifier is the MF. DF Characteristics The DF also is a container or a directory file in the same vein as the MF.The DF forms a subdirectory within the file hierarchy rooted in the MF.

A DFalso can be identified by a file identifier. A DF must be given a unique fileidentifier within the DF (or MF) that contains it.

This allows for the creationof a unique path designation for a file (i.e., a path is simply theconcatenation of the file identifiers of the file in question, and of all theDFs between the file in question and its containing DF or MF). A DF also can be referenced by a name that may be from 1 to 16 byes long.

Thenaming conventions for the DF name are found in the ISO/IEC 7816-5specification. EF Characteristics The EF is the leaf node of the file hierarchy. It is the file that actuallycontains data. There are two variants of EFs: an internal EF, which is to beused by applications on the card, and a working EF, which is used as a storagemechanism for information used by an off-card application.

Within a specific DF, an EF may be identified by a short (5-bit) identifier.There are four variants of EFs as illustrated in: • a transparent file • a linear, fixed-length record file • a linear, variable-length record file • a cyclic, fixed-length record file Smart card file system file types. A transparent file can be viewed as a string of bytes. When a command is usedto read or write information from a transparent file, it is necessary to providea byte offset (from the start of the file) to the specific byte (within thetransparent file) where reading or writing should begin. A command to read orwrite information from/to a transparent file will also contain a counter orlength of the byte string to be read or written to the file. Fixed- or variable-length record files are, as the name suggests, files thatcomprise subdivisions called records.

Records (within a file) areidentified by a sequence number. In a fixed-length record file, all the recordscontain the same number of bytes. In a variable-length record file, each recordin the file can contain a different number of bytes. As might be suspected, avariable-length record file generally has a significantly higher overhead inread/write access time and in the amount of administrative (data storage)overhead required by the file system. A cyclic file is a rather unique (to smart card file systems) structure. Itallows applications to access a file in a consistent, transparent fashion andyet have the file system itself map this access into a variety of differentphysical files. This allows the limits of erase and rewrite cycles on EEPROMmemory to be somewhat mitigated.

A cyclic file is best thought of as a ring of records. Each successive writeto the file performs the operation on the next physical record in the ring. Readoperations are performed on the last physical record that was actually writtento. File Access Commands To manipulate the smart card file system, an application-level protocol isdefined in the form of a collection of functions for selecting, reading, andwriting files.

These functions are discussed qualitatively in the followingsections. The Select File Command CLA INS P1 P2 Lc Data C0 16 A4 16 00 16 00 16 02 16 3F 16 00 16 The Select File command is used to establish what may bethought of as a logical pointer to a specific file in the smart card's filesystem. After a file is selected by this command, any subsequent commands, suchas those to read or write information, will operate on the file pointed to bythis logical pointer. Access to the smart card's file system is notmultithreaded (from the card's viewpoint), but it is possible to havemultiple such logical pointers in play at any point in time. This is done byusing the Manage Channel command to establish multiple logical channelsbetween the reader-side application and the card.

Commands to access differentfiles can then be multiplexed (by the reader-side application) allowingdifferent files on the card to be in various states of access by the reader-sideapplication at the same time. The primary piece of information the command must convey (from thereader-side application to the smart card's APDU processor) is theidentification of the file to which this logical pointer must point. Thisidentification can be provided in three ways (with the specific addressingmechanism being indicated in the data field of the Select File commandAPDU): • by file identifier (2-byte value) • by DF name (string of bytes identifying the DF) • by path (concatenation of file identifiers) The Read Binary Command CLA INS P1 P2 Lc Data C0 16 B0 16 00 16 00 16 10 16 empty The Read Binary command is used by a reader-sideapplication to retrieve some segment of an EF on the card. The EF being accessedmust be a transparent file; that is, it cannot be a record-oriented file.

If a Read Binary command is attempted on a record-oriented EF, the commandwill abort with an error indicator being returned by the card to the reader-sideapplication. Two parameters are passed from the reader-side application to the card forthis command: an offset pointer from the start of the file to initial byte to beread, and the number of bytes to be read and returned to the reader-sideapplication. The Write Binary Command CLA INS P1 P2 Lc Data C0 16 D0 16 01 16 01 16 01 16 FF 16 The Write Binary command is used by a reader-sideapplication to put information into a segment of an EF on the card. The filebeing accessed must be a transparent file; that is, it cannot be arecord-oriented file. If a Write Binary command is attempted on arecord-oriented EF, the command will abort with an error indicator beingreturned by the card to the reader-side application. Depending on the attributes passed from the reader-side application to thecard in the Write Binary command, the command can be used to set a seriesof bytes in the EF (i.e., set selected bits within the designated bytes to avalue of 1), clear a series of bytes in the EF (i.e., set selected bitswithin the designated bytes to a value of 0), or do a one-time write of aseries of bytes in the EF. The Update Binary Command CLA INS P1 P2 Lc Data C0 16 D6 16 01 16 01 16 01 16 FF 16 The Update Binary command is used by a reader-sideapplication to directly erase and store a set of information (bytes) into asegment of an EF on the card.

The file being accessed must be a transparentfile; that is, it cannot be a record-oriented file. If an Update Binarycommand is attempted on a record-oriented EF, the command will abort with anerror indicator being returned by the card to the reader-side application. The Update Binary command provides the functions that would normallybe associated with a file write command. That is, a string of bits provided inthe command are actually written into the EF on the card, with those bytepositions in the file on the card being erased first. The net result is that thestring of bytes found in the designated position within the EF on the card isexactly the string sent by the reader-side application in the UpdateBinary command.

Input parameters for the command include an offset pointer from the start ofthe file and a byte count of the total number of bytes to be written. The Erase Binary Command CLA INS P1 P2 Lc Data C0 16 0E 16 01 16 01 16 01 16 06 16 The Erase Binary command is used by a reader-sideapplication to erase (set the value to 0) a string of bits within an EFon a card. The file being accessed must be a transparent file; that is, itcannot be a record-oriented file. If an Erase Binary command is attemptedon a record-oriented EF, the command will abort with an error indicator beingreturned by the card to the reader-side application.

Two parameters are specified as part of the command: an offset from the startof the EF to the segment of bytes within the file to be erased and the number ofbytes within that segment. The Read Record Command CLA INS P1 P2 Lc Data C0 16 B2 16 06 16 04 16 14 16 empty The Read Record command is a command sent by areader-side application to read and return the contents of one or more recordsin an EF on a card. This command must be executed against a record-oriented EF.If it is applied to a transparent EF, the command will abort and an errorindicator will be sent from the card back to the reader-side application. Depending on the parameters passed through the command, the one designatedrecord is read and returned, or all the records from the beginning of the fileto the designated record are read and returned, or all the records from thedesignated record to the end of the file are read and returned. The Write Record Command CLA INS P1 P2 Lc Data C0 16 D2 16 06 16 04 16 14 16 53 16 61 16 6C 16 6C 1679 16 20 16 47 16 72 16 6E 16 00 16 00 16 00 16 00 16 00 16 The Write Record command is a command sent by areader-side application to write a record into an EF on the card.

This commandmust be executed against a record-oriented EF. If it is applied to a transparentEF, the command will abort and an error indicator will be sent from the cardback to the reader-side application.

In the sample command sequence notedpreviously, 14 (hexadecimal) characters will be written into the currentlyselected record beginning at the sixth character position in that record. Thecharacters to be written are contained in the Data field (i.e., the hexadecimalrepresentation for 'Sally Green'). As with the Write Binary command, this command can actually be used toachieve one of three results: a one-time write of a record into the EF, settingof specific bits within a specific record in the EF, or clearing of specificbits within a specific record in the EF. Several addressing shortcuts may be used in this command to specify therecord to be written to, including the first record in the EF, the last recordin the EF, the next record in the EF, the previous record in the EF, or aspecific record (identified by number) within the EF. The Append Record Command CLA INS P1 P2 Lc Data C0 16 E2 16 00 16 00 16 14 16 53 16 61 16 6C 16 6C 1679 16 20 16 47 16 72 16 6E 16 00 16 00 16 00 16 00 16 00 16 The Append Record command is a command sent by areader-side application to either add an additional record at the end of alinear, record-oriented EF on a card or to write the first record in a cyclic,record-oriented EF on a card. If it is applied to a transparent EF, the commandwill abort and an error indicator will be sent from the card back to thereader-side application.

In the preceding example, P1 is an unused parameter and is always00 16. P2 is the short identifier of the file to which the recordappend will apply. Lc specifies the number of characters in the record to beappended and the Data field contains the characters to be appended—in thiscase, the hexadecimal representation of 'Sally Green.' That is, forwhatever end, this command appends the words 'Sally Green' in a recordonto the end of the selected file. The Update Record Command CLA INS P1 P2 Lc Data C0 16 DC 16 06 16 04 16 14 16 53 16 6 161 6C 16 6C 1679 16 2 160 47 16 72 16 6E 16 00 16 00 16 00 16 00 16 00 16 The Update Record command is a command sent by areader-side application to write a record into an EF on the card. This commandmust be executed against a record-oriented EF. If it is applied to a transparentEF, the command will abort and an error indicator will be sent from the cardback to the reader-side application.

As with the Update Binary command, this command is used to write aspecific record into an EF. The net result of the operation is that the specificrecord in the EF is erased and the new record specified in the command iswritten into the EF. Acer 3g Connection Manager Windows 7. Administrative Commands The master-slave command protocol specified by ISO/IEC 7816-4 is quiterestrictive in its ability to accommodate the wide variety of commands that youmight want to access on a smart card. In an attempt to compensate for some ofthe syntactic shortcomings, ISO/IEC 7816-4 also defines a number ofadministrative commands that allow a wider latitude of command structures andresponses. The Get Response Command CLA INS P1 P2 Lc Data C0 16 C0 16 00 16 00 16 14 16 empty The Get Response command is another command that allowsthe use of the T=0 link-level protocol for conveying the full range of APDUs.Specifically, the Case 4 type of APDU body cannot be supported with the T=0protocol.

That is, you can't send a body of data to the card and thenreceive a body of data back as a direct response to that command. For this typeof command, using the T=0 protocol, the initial command results in a responsethat indicates more data is waiting (in the card). The Get Responsecommand is then used to retrieve that waiting data.

It should be noted that no other command can be interleaved between theoriginal command and the Get Response command. The Manage Channel Command CLA INS P1 P2 Lc Data C0 16 70 16 00 16 01 16 00 16 empty The Manage Channel command is used by the reader-sideapplication to open and close logical communication channels between it and thecard. When the card initially establishes an application-level protocol with thereader-side application (i.e., following the ATR sequence) a basic communicationchannel is opened. This channel is then used to open and/or close additionallogical channels via the Manage Channel command. The Envelope Command CLA INS P1 P2 Lc Data C0 16 C2 16 00 16 00 16 07 16 C0 16 A4 16 00 16 3F 16 00 16 The Envelope command is a command that supports the useof secure messaging via the T=0 link-level protocol.

In secure messaging, thefull command APDU should be encrypted. However, because the CLA and INS bytesfrom the APDU overlay elements of the transmission protocol data units (TPDU),these bytes (in the TPDU) cannot be encrypted if the link-level protocol isstill to work correctly.

So the Envelope command allows a full APDU to beencrypted and then included in the Envelope command's data section(of its APDU). The card's APDU processor can then extract the'real' command and cause it to be executed. The Get Data Command CLA INS P1 P2 Lc Data C0 16 CA 16 02 16 01 16 14 16 empty The Get Data command is a command sent by a reader-sideapplication to read and return the contents of a data object stored within thefile system on the card. This command is essentially the complement of the Put Data command (defined in the next section). This command tends to bevery card specific in its internal implementation. However, the semantics of thecommand are well defined. That is, the definition of just what constitutes adata object varies widely from card to card, but what the command does should beconsistent from card to card.

Thus, for retrieving a small amount ofinformation, this command might well be preferable to retrieving informationfrom a specific file. The Put Data Command CLA INS P1 P2 Lc Data C0 16 DA 16 02 16 01 16 01 16 FF 16 The Put Data command is a command sent by a reader-sideapplication to put information into a data object stored within the file systemon the card. This command tends to be very card specific in its implementation;however, it is relatively general in its specification.

So, the fact that thedefinition of just what constitutes a data object varies widely from card tocard does not necessarily mean that the semantics of the command varies fromcard to card. In fact, the attractive feature of this command is the fact thatyou do not need to know the identity of a specific file into which the'data' is to be stored. This tends to make the command similar acrossa variety of different smart cards. An application, should it need to store onlya modest bit of information, can do so with this command and be moderatelyassured that the command will work on a variety of different smart cards.