Commands for cryptographic algorithms are very important for many applications. For example, they make it relatively easy to use smart cards as encryption and decryption devices or to verify digital signatures. Many smart card operating systems have their own command sets for executing cryptographic algorithms. Smart card commands such as ENCRYPT, DECRYPT, SIGN DATA and VERIFY SIGNATURE have arisen because there was no standard for this sort of functionality. However, commands specially designed for processing cryptographic algorithms have now been defined in the ISO/IEC 7816-8 standard. In the ISO/IEC 7816-8 standard, the functions related to cryptography are split between two commands. The MANAGE SECURITY ENVIRONMENT (MSE) command allows various general constraints to be set before the cryptographic algorithm is executed. This command passes a ‘template’ to the card, and this template contains the relevant parameters. They remain valid until they are replaced using a newMANAGE SECURITY ENVIRONMENT command. The templates themselves consist of TLV-coded data objects, which provide a high degree of flexibility (and unfortunately, complexity) for transferring parameters. After all the options for the cryptographic function have been configured using the MANAGE SECURITY ENVIRONMENT command, the PERFORM SECURITY OPERATION (PSO) command can be invoked. A wide variety of security operations can be performed using this command, provided that they are supported by the smart card operating system. However, the number of options with this command is so large that this support is not always mandatory. Although PERFORM SECURITY OPERATION is coded using only one instruction byte, it has eight fundamentally different functions that are distinguished by the P1 parameter byte. This was done because the number of codes remaining for coding commands has becomesomewhat scant in the last while.

Since the PERFORM SECURITY OPERATION command can be used in so many different ways, we have divided the following description of its functions along the lines of its various options, without describing any of them in detail. PERFORMSECURITYOPERATION with theCOMPUTECRYPTOGRAPHIC CHECKSUM option is used to compute a cryptographic checksum (CCS), which is commonly referred to as a MAC. The padding, as well as the key to be used, can be either implicitly provided by the operating system or explicitly supplied using the MANAGE SECURITY ENVIRONMENTcommand. The counterpart to this command option is theVERIFYCRYPTOGRAPHIC CHECKSUM option, which computes the cryptographic checksum of the transferred data and compares it with a reference value, which is also transferred with the command. The result of this operation is a match/no-match decision, which is returned to the terminal. The ENCIPHER and DECIPHER options are provided for the pure encryption and decryption of data. The ENCIPHER option is used to encrypt the data transferred with the command. The encryption algorithm to be used can be selected, according to the options available in the operating system, by first sending the MANAGE SECURITY ENVIRONMENT command. Similarly, the mode of the encryption algorithm must also be set in advance by parameters transferred before the command is issued.With a block encryption algorithm, it is also possible to select the ECB or CBC mode. Since the length of the data block sent to the card is not always an exact multiple of the block size of the cryptographic algorithm, the padding method must be defined via an additional parameter. The address of the key stored in the smart card that is to be used by the algorithm to encrypt the data is also important. The reverse function of ENCIPHER is DECIPHER.With this function, the transferred data can be decrypted in the same mode as that used for ENCIPHER. Naturally, the smart card must know the appropriate key, algorithm mode and padding mode. This information must be passed to the card’s operating system using the MANAGE SECURITY ENVIRONMENT

With the introduction of public-key algorithms into smart card applications, therewas a need for suitable commands for using the newly available functions. Smart cards are particularly suitable for digital signature applications, since the private key for the signature algorithm can be securely stored in memory, where it cannot be read. The ISO/IEC 7816-8 standard describes four command options that can be used for digital signatures. The HASH option of the PERFORM SECURITY OPERATION command can be used to compute a hash value. The command may transfer either the data to be hashed or a hash value already computed outside the smart card along with the data needed for the final step of the computation. In the latter case, the hash computation for the final block is performed in the card. The advantage of the latter method is that the hash value can be generated significantly faster outside of the card, but the final step still occurs inside the card. From a purely cryptological perspective, this provides only a small amount of extra security, but it does somewhat limit the possibilities for manipulating the hash value. For this reason, it is widely used in practice. Since the amount of data to be hashed is usually larger than maximum allowed length of a command data field, the HASH option employs ‘layer-7’ chaining, which means that the data blocks are logically chained at the application level. The final data block to be hashed includes a marker that informs the command that it is the final block for the hash process. This command option also has its own options. The computed hash value can either be transferred immediately to the terminal in the response to the command or stored in the card for use with a subsequent command. The padding and the key to be used are defined as necessary using a prior MANAGE SECURITY ENVIRONMENT command, in the same way as for previously described commands.The COMPUTEDIGITALSIGNATUREoption can be used for signing data. The data string to be signed, which has usually been compressed to a hash value, must be passed to the smart card if it is not already present in the card as the result of a previous PERFORM SECURITY OPERATION command with the HASH option. The COMPUTE DIGITAL SIGNATURE option also allows the data to be signed to be transferred directly to the card. The data can then be hashed in the card before the signature is generated. For large amounts of data, ‘layer-7’
chaining can be used as with the HASH option.

If the length of the hash value does not correspond to the input data length of the public-key algorithm, padding must be added. The options for this are set by parameters of the MANAGE SECURITY ENVIRONMENT command, which is also used to identify the key to be used. The verification counterpart to the COMPUTE DIGITAL SIGNATURE option is provided by the VERIFY DIGITAL SIGNATURE option. In principle, any sufficiently fast digital computer could be used to verify a digital signature, since the necessary key is public. However, in many cases the validity of the public key must first be verified using an additional digital signature. This is certainly a security consideration, so this should not be performed using an insecure computer. In order to verify a digital signature, the associated public key must either be implicitly known to the smart card or be explicitly made known to the card using the command option VERIFY CERTIFICATE, which is described immediately below. The data to be verified may be passed by VERIFY DIGITAL SIGNATURE either directly or in the form of the associated hash value. All other parameters are the same as for the COMPUTE DIGITAL SIGNATURE option. In open systems, public keys for verifying digital signatures are usually signed using the private key of the certification authority. The authenticity of a public key must be verified before it is used, since this is the onlyway to be sure that the key is not a forgery. This verification must take place in a secure environment, such as a smart card, since it would otherwise be subject to manipulation. The VERIFY CERTIFICATE command option is provided specifically for verifying signed public keys, which are also called ‘certificates’. Once a public key has been identified as authentic, it can either be stored permanently in the smart card or be used with an immediately following VERIFY DIGITAL SIGNATURE command. Figure 7.17 illustrates how the commands described above can be used to generate a digital signature and then verify it. If a smart card operating system supports generating key pairs for asymmetric cryptographic algorithms, this process can be instigated by the ISO/IEC 7816-8 GENERATE PUBLIC KEY PAIR command. All parameters needed for key generation must be set in advance using theMANAGE SECURITY ENVIRONMENT command.