Method and device for automatic validation of a computer program using cryptography functions

ES 2 298 516 T3

DESCRIPTION

Procedure and device for automatic validation of a computer program that uses cryptography functions.

The present invention relates to a method and a device for automatic validation of a computer program.

The present invention relates more precisely to a procedure for the automatic validation of a computer program capable of accessing a protected memory and an unprotected memory, the program using at least one encryption function and, at least, a decryption function.

The invention finds an advantageous, but not limiting, use in the personalization of microcircuit cards.

In a known way, the personalization of microcircuit cards comprises steps of processing sensitive data, that is, of secret data that is to be protected from any fraudulent manipulation.

By way of example, such a treatment can consist of the following successive operations:

- reception of an encrypted input data;

- decryption of this data encrypted with a secret key, the result of this decryption operation being a first sensitive data;

- logical operation, for example offset, on this first sensitive data and obtaining a second sensitive data; ^Y

- encryption of the second sensitive data using a second secret key.

In the field of personalization of microcircuit cards, different solutions are known to carry out such treatments that preserve, from any fraudulent manipulation, the sensitive data obtained in the course of treatment.

A first known solution consists in manufacturing a specific microcircuit card, called a "root card", which implements the different operations mentioned above.

In effect, the use of a root card thus defined makes it possible to obtain absolute security, this data being temporarily archived, for manipulation, in an internal and protected memory of the microcircuit card.

Unfortunately, a root card only allows to carry out treatments for which it has been developed.

This implies that, in order to put a new treatment into practice, it is necessary to develop a specific card mask adapted for this treatment, which requires not negligible costs and development time.

In order to alleviate this drawback, the person skilled in the art of microcircuit card personalization sometimes uses, in a known way, protected platforms, adapted to carry out different types of processing of sensitive data.

Such platforms can be made up of protected computer systems or specific electronic cards.

In this context, the performance of a particular treatment comprises a first phase of specification and development of a software putting into practice the different operations of this treatment, and taking into account the characteristics of these protected platforms.

During a second phase, the software thus developed is manually verified by specialists from these platforms, who, in the course of this particular treatment, verify that sensitive data cannot be accessed by third parties with fraudulent intent.

This second solution, although more flexible to use than the root card, also requires relatively long development times, in particular because of the manual verification phase of the program by a specialized company.

The present invention makes it possible to solve the aforementioned problems.

The object of the present invention is, more particularly, a procedure for the automatic validation of a computer program capable of accessing a protected memory and an unprotected memory, using the

ES 2 298 516 T3 programs at least one encryption function and at least one decryption function; This validation procedure includes a verification stage during which the following is verified:

- that any function adapted to read data from the protected memory and to produce data in the unprotected memory is an encryption function; Y

- that any data produced by the decryption function is stored in the protected memory.

In what follows in this document, a distinction will be made between a "protected memory", that is, a memory accessible only by a verifier program that implements this validation procedure, and an accessible "unprotected memory", in particular, by a user of this verifier program, or by other computer programs.

In a first embodiment, these protected and unprotected memories are different physical memories, corresponding to different physical components.

In a preferred embodiment, the protected and unprotected memories are bands of different registers of the same physical component, the management and control of access to these memories being ensured by means of software known to the person skilled in the art, for example: for example by low-level memory management functions provided by a protected operating system.

This validation procedure is particularly advantageous, because, unlike the root card and the protected platform of the prior art, it allows any computer program that uses cryptography functions to be validated.

This, in particular, verifies that any function adapted to read data from the protected memory and to produce data in the unprotected memory is an encryption function, which makes it possible to ensure that only encrypted data is accessible by the user of this verifier program. , or by the other computer programs.

The validation method according to the invention also verifies that any data produced by the decryption function, in particular any sensitive data, is stored in the protected memory.

According to a first characteristic, the computer program also uses at least one non-cryptographic function chosen from a logical function, a function for generating a random number, or an integrity control function.

Thus, the validation procedure allows validating any type of program that uses encryption, decryption and non-cryptographic functions.

According to a preferred characteristic of the invention, the computer program being in source code, the procedure, prior to the verification stage, comprises a stage of compiling this source code in binary script, the verification stage being carried out in the script binary thus generated.

This preferred embodiment makes it possible to obtain an additional level of security because it prevents any fraudulent modification that could be made to the source code after the verification stage.

The computer program is, for example, a sensitive data generation program.

In a preferred embodiment, the computer program is a sensitive data transformation program. The latter, for example, receives first sensitive data, for example protected keys, performs decryption operations and logical operations on this first sensitive data and, after decryption, supplies other sensitive data, for example a secret code.

According to another particularly advantageous characteristic, each function used by the computer program is associated with at least one operating mode that defines at least one protected and unprotected memory access rule, the operating mode being memorized in a verification table used during the verification stage.

These operating modes are used by programmers during the specification and development stage of a particular treatment.

According to the invention, these rules impose, especially, on any decryption function, to store the data produced in a protected memory.

In a preferred embodiment, the validation procedure further comprises:

- a protected and unprotected memory allocation stage;

ES 2 298 516 T3

- a stage of loading, in a working memory, a verifying program of the binary script, the verifying program being adapted to implement the verification step; Y

- a stage of loading the binary script into the work memory.

These different stages are implemented by a main program, which thus defines the memory environment used by the verifier program for verifying the binary script.

Thus, a use is found in the field of personalization of microcircuit cards, but also in various fields, such as, for example, electronic transactions on telecommunications servers.

The invention also relates to a compiler that implements a validation procedure such as that succinctly described above.

Such a compiler can advantageously be used in a microcircuit card personalization software chain.

The invention also relates to a method of executing a computer program capable of accessing a protected memory and an unprotected memory, the program using at least one encryption function and at least one decryption function.

Prior to the execution of each function, the execution method according to the invention implements a verification step, such as that briefly described above.

According to this execution procedure, prior to the execution of each function of the program, it is verified that this function preserves, in accordance with the verification stage succinctly described above, the security of the sensitive data.

An execution procedure of this type is particularly reliable, because it prevents any manipulation of the binary script, between the verification and the execution of a function.

This, of course, can be used for the personalization of microcircuit cards.

More generally, it can be used for the transformation or generation of sensitive data, for example in the field of telecommunications, for the generation of keys in a telecommunications server.

According to another aspect, the invention relates to an integrated electronic circuit adapted to implement a validation procedure or an execution procedure such as those briefly described above.

Such an integrated circuit can be modeled, for example, by means of the VHDL language known to the person skilled in the art.

This can also be realized in the form of a programmable electronic component.

The invention also relates to a microcircuit card and to a computer system comprising an integrated electronic circuit, such as that briefly described above.

According to another aspect, the invention relates to a protected exploitation system that implements a validation procedure such as that described above.

An operating system of this type can be used, advantageously, in the microcircuit card industry, because it allows to implement the security functions in the lowest layer of software of these microcircuit cards, which practically prevents any type of fraudulent operations. .

In the field of microcircuit cards, an operating system of this type also makes it possible to protect the execution of an application loaded afterwards, even after these cards are put on the market (in English, “post-insurance”). .

The invention also relates to a microcircuit card and to a computer system comprising an operating system of this type.

Correlatively, the invention relates to a device for validating a computer program capable of accessing a protected memory and an unprotected memory, the program using at least one encryption function and at least one decryption function.

The validation device comprises a verifying program adapted to certify:

ES 2 298 516 T3

- that any function adapted to read data from the protected memory and to produce data in the unprotected memory is an encryption function; Y

- that any data produced by the decryption function is stored in the protected memory; Y

The invention also relates to a protected exploitation computer system, comprising:

- means of compiling a computer program into binary script

- means for loading the binary script into a working memory;

- means for allocating a protected memory and an unprotected memory; Y

- a validation device such as that briefly described above.

Being the advantages and particular characteristics of the compiler, the execution procedure, the protected operating system, the microcircuit card, the validation device and the computer system, the same as those set out above relating to the validation procedure in accordance with the invention, these will not be discussed here.

Other aspects and advantages of the present invention will become apparent more clearly upon reading the following description of particular embodiments, this description being given solely by way of non-limiting example and made with reference to the attached drawings, in which which:

figure 1 represents a syntax table according to the present invention;

figure 2 represents a check table according to the present invention;

figure 3 is a flow chart representing the main stages of a main program according to the present invention;

figure 4 is a flow chart representing the main stages of a verification procedure according to the present invention; Y

figure 5 represents a computer system comprising a validation device according to the present invention.

On the other hand, the description is accompanied by the following annexes:

- Annex A: example of a computer program capable of being validated by a validation procedure according to the present invention, and executed by an execution procedure according to the present invention;

- Annex B: binary code obtained after compiling the computer program in Annex A.

In annex A, an example of a computer program P is given in source code capable of being validated by an automatic validation procedure according to the present invention and executed by an execution procedure according to the present invention.

This computer program P comprises a sequence of operations, each operation implementing a decryption function, an encryption function or a non-cryptographic function.

During the development of a computer program of this type, the analyst must respect, for each operation, a syntax memorized in a syntax table TS, an example of which is given in figure 1.

More precisely, each operation comprises:

- an identifier of the function;

- a list of arguments; Y

- a character representative of the end of the operation, for example the character

Thus, the first operation declared in line a1 is a decryption operation, which uses a DES-1 decryption function identified by the DES-1 identifier, this function using three arguments:

- INPUT, 8 octet address band containing the data to be decrypted;

ES 2 298 516 T3

- KEY, reference to a cryptographic key, this reference being memorized in the form of a string of L characters; Y

- OUTPUT, 8 octet address band in which the result of the decryption function must be stored.

Advantageously, in the embodiment described above, the programmer does not know the cryptographic key, but only its KEY reference in the form of a character string. This mode of implementation allows avoiding any fraud on the part of the programmer.

Likewise, the second operation declared in line 2 is an integrity check operation, which uses an integrity check function CHECKSUM_XOR identified by the identifier CHECKSUM_xOr, using this function two arguments:

- INPUT, 8 octet address band containing the input data of the logic function to be operated; Y

- OUTPUT, address in 8 octets in which the result of the logic function must be stored.

Finally, the third operation declared in line a3, is an encryption operation, which uses a DES encryption function identified by the DES identifier, using this function three arguments:

- INPUT, 8 octet address band containing the data to be encrypted;

- KEY, reference to a cryptographic key, this reference being memorized in the form of a string of L characters; Y

- OUTPUT, 8 octet address band in which the result of the encryption function must be stored.

Each function is also associated with an operating mode that defines at least one memory access rule, the operating modes being memorized in a verification table such as that represented in figure 2.

Figure 2 represents a check table according to the present invention.

For each encryption and decryption function and each logical function, the verification table TV comprises as many lines as there are operating modes for this function, each operating mode defining access rules to the protected MS and unprotected memories MNS.

For example, the DES encryption function comprises four operating modes because, in the embodiment described here, any encryption function is authorized to read and write to the protected and unprotected memories, without any particular limitation.

On the contrary, in the last two lines of the verification table TV, it appears that the decryption function DES1 comprises only two operating modes, any decryption function being authorized, according to the present invention, to produce data only in one memory protected MS.

Referring to Fig. 3, a main program implementing an automatic validation procedure and an execution procedure of the computer program P according to the present invention is now described.

The validation procedure comprises a previous stage E300 of compilation of the computer program P of annex A, this compilation stage generating a binary EXE script.

Referring to Annex B, the binary EXE script resulting from this compilation stage will now be described.

In order to simplify the description, the bytes of the binary EXE script are grouped by lines b1 to b20.

The first two octets of the EXE script (line b1) correspond to the size of the binary script, that is 6C in hexadecimal notation.

The next octet (line b2) corresponds to the number of operations of the computer program P, that is, 3.

The octets regrouped in lines b3 to b8 are the octets generated by the compilation of the first operation (line a1, annex A).

Likewise, the bytes regrouped in lines b9 to b13 are the bytes generated by the compilation of the second operation (line a2, annex A).

ES 2 298 516 T3

Finally, the bytes regrouped in lines b14 to b19 are the bytes generated by the compilation of the third and last operation (line a3, annex A).

In each of these groups:

- the first line (lines b3, b9 and b14) is made up of an octet that represents the number of octets, in hexadecimal notation, generated by compiling the corresponding operation, namely, respectively, 24, 16 and 24 for the functions DES-1, CHECKSUM_XOR and DES;

- the second line (lines b4, b10 and b15) is made up of an octet generated by compiling the identifier of the corresponding function, namely, respectively, 22, 53 and 21 for the DES1, CHECKSUM_XOR and DES functions;

- the third line consists of an octet (lines b5, b11 and b16) equal to the number of arguments of the corresponding function, namely, respectively, 3, 2 and 3 for the DES-1, CHECKSUM_XOR and DES functions;

- the fourth line (lines b6, b12 and b17) is made up of the octets generated by compiling the first argument of the corresponding function;

- the fifth line (lines b7, b13 and b18) is made up of the octets generated by compiling the second argument of the corresponding function; Y

- the sixth line (lines b8 and b19) is constituted, where appropriate, by the octets generated by compiling the third argument of the corresponding function.

In the embodiment described here, the compilation of an argument first generates a first byte representative of the memory area in which the read or write operation that is operated on this argument must be performed.

In the example described here, four memory zones are used:

- an unprotected entry zone, IN_BUF; represented by octet 01 (line b6):

an unprotected output area, OUT_BUF, represented by octet 02 (line b19);

a calculation protected area, PRIVATE, represented by octet 04 (lines b8, b12 and b13); Y

- a protected key storage area, represented by octet 05 (lines b7 and b18).

Compiling an argument then generates a second octet representative of the size of the argument. In the example given here, this size is 8 octets when the argument is an address, or 12 octets (0C in hexadecimal notation) when the argument is the KEY key consisting of the 12 characters “CIPHER.TEST1”.

The compilation of an argument finally generates a group of octets representative of the value of the considered argument.

In the embodiment described here, a band of addresses is represented in the P program using the notation ZONE / OFFSET / LENGTH, where:

- ZONE represents the type of memory zone that contains this address band, this type being chosen from the unprotected input zone IN_BUF, the unprotected output zone OUT_BUF, the PRIVATE calculation protected zone, and the memorization protected zone of keys;

- OFFSET represents the offset (“offset” in English) of the beginning of this address band with respect to the beginning of the zone; Y

- LENGTH the size of the address strip.

According to this notation, the second argument (OUTPUT = [PRIVATE / 08/01]) of the logical operation CHECSUM_OXR (line a2, Annex A), means that the result of this logical operation must be memorized in the calculation protected area PRIVATE, in a band extending by one octet, starting from the eighth octet in this area.

In the embodiment described here, the binary script ends in a series of bytes (line b20) corresponding to a cryptographic signature obtained from at least a part of the bytes that make up this script.

ES 2 298 516 T3

The compilation step E300 is followed by a step E305 in the course of which the main program receives:

- on the one hand, input data of the computer program P, this input data being able to comprise protected keys; Y

- on the other, the binary EXE script generated during the E300 compilation stage.

In the embodiment described here, the protected keys are stored in the protected key storage area.

The receiving stage E305 is followed by a stage E310 in the course of which the main program dynamically allocates a protected memory MS and a protected memory MNS.

This allocation step is known to those skilled in the art and can be performed, for example, by means of the malloc () system function.

In any case, this allocation step E310 makes it possible to obtain a first BUFF_MNS address pointer, this BUFF_MNS pointer pointing to the unprotected memory and a second BUFF_MS address pointer, pointing to the protected memory.

In the embodiment described here, the unprotected MNS memory thus allocated is subdivided into two areas:

- the unprotected entry zone, IN_BUF; Y

- the unprotected exit zone, OUT_BUF.

The protected memory MS is also subdivided into two areas:

- the protected area of ​​calculation, PRIVATE; Y

- the protected password storage area.

In a preferred embodiment, during the same step E310, a work memory MT is also assigned, indicated by the BUFF_EXE pointer, this work memory comprising the binary EXE script received during step E305.

The memory allocation step E310 is followed by a binary script integrity verification step E315.

This step E315 can be carried out, for example, by verifying the cryptographic signature of the binary EXE script, as described above referring to line b20 of annex B.

This optional step E315 of script integrity verification allows to reinforce the security of the validation procedure.

The optional step E315 for verifying the integrity of the script is followed by a step E320 in the course of which the number of operations N of the computer program P is obtained, this number N being stored in a register of the same name as the memory of work mt.

In the embodiment described here, the number of operations N is the third octet (line b2) of the binary EXE script.

When the optional step E315 of verifying the integrity of the script is not implemented, the step E320 of obtaining the number of operations is consecutive to the step E310 of assigning the memories described above.

The step E320 of obtaining the number of operations N is followed by a test E325 in the course of which it is verified whether the content of the register N of the working memory MT is equal to 0.

If this is not the case, the E325 test result is negative.

This test is then followed by a step E330 in the course of which the identifier of the function used by the first operation of the computer program P is obtained in the binary script.

In the example in Annex B, the identifier thus obtained is 22, representative of the DES-1 function (line b4).

ES 2 298 516 T3

This step E330 is followed by a step E335 during which the arguments of this function are obtained in the binary script.

In practice, the stage E335 of obtaining the arguments comprises:

- a first substep during which the syntax table TS of figure 1 is searched for the list and the size of each of the arguments of the function; Y

- a second substep in the course of which the corresponding number of bytes is read in the binary script.

The step E335 of obtaining the arguments of the function is followed by a step E340 of calling a verification procedure of the identified function in the course of steps E330 and E335.

Referring to Figure 4, the main steps E400 and E440 of the verification procedure will now be described.

During the first stage E400 of the verification procedure, the rules for accessing the protected and unprotected memories are obtained from the verification table in Figure 2, these rules being defined in the operating mode of the function identified in step E330.

The step E400 of obtaining the rules is followed by a test E410 in the course of which it is verified whether the access rules have been respected.

In practice, this verification stage is carried out by verifying:

- that all the read and write operations that, according to these rules, must be carried out in a protected memory, are carried out in the address band pointed by the BUFF_MS pointer; Y

- that all the writing and reading operations to be done in the unprotected memory are carried out in the address band pointed to by the BUFF_MNS pointer.

For example, going through lines b14 to b19 of Annex B, it is identified that the DES function (line b15) performs:

- a read operation of the band consisting of the first 9 octets of the PRIVATE calculation protected area (octet 04, line b17), and

- a write operation in the band made up of the first 10 bytes of the unprotected output area, OUT_BUF (byte 02, line b19), these memory accesses being in accordance with the second operating mode of the DES function, in accordance with the TV check table.

When all the memory access rules have been respected, the E410 test result is positive.

This test is then followed by step E420 in the course of which the operation in course of treatment is executed.

On the contrary, if at least one of the access rules has not been respected, the result of the E410 test is negative.

This test is then followed by a step E430 in the course of which the content of the unprotected output area OUT_BUF is erased.

The step E340 of clearing the output memory is followed by a step E440 of notifying an error to the programmer of the computer program P.

In any case, steps E420 and E440 complete the verification procedure according to the invention.

These stages are followed by the E345 validation test that will now be described, returning to Figure 3.

In the course of this validation test E345, it is verified whether the verification procedure described above referring to figure 4 has ended by an operation execution (step E420) or by an error notification step (step E440).

When the verification procedure is finished normally, that is, by the operation execution step E420, the result of the E345 test is positive.

This test is then followed by a step E350 in the course of which the content of the N register is decreased by one unit.

ES 2 298 516 T3

Step 350 is followed by test E325 already described, during which it is verified whether register N contains the value 0.

When the result of this test is negative, the step E330 already described is executed in the course of which the identifier of the function that constitutes the second operation of the computer program P is read in the binary script EXE.

Steps E325 to E350 thus constitute a loop during which, if the computer program P respects the set of memory access rules, all the operations of this program are validated and executed.

In contrast, when the verification procedure is terminated by an error notification, the E345 test result is negative.

This test is then followed by step E355 described below.

When all the operations of the computer program P have been validated by the loop constituted by steps E325 to E350, the result of test E325 is positive.

In this case, test E325 is followed by a step E355 in the course of which the content of the output area OUT_BUF is transmitted to the user of the main program, or to another computer program for processing the output data.

Step E355 is followed by a step E360 for releasing and erasing the memories assigned in step E310.

This E360 step ends the main program according to the present invention.

Figure 5 schematically represents a computer system comprising a validation device according to the present invention.

This computer system comprises first of all a compiler that, starting from a computer program P in source code, makes it possible to generate a binary EXE script as defined above.

The computer system also includes a protected operating system. This protected operating system comprises means for allocating a protected memory MS and an unprotected memory MNS.

In a preferred embodiment, these allocation means are, in practice, software functions known to those skilled in the art, for example the malloc () function. This allocation function returns, in a known way, to an address pointer that delimits the beginning of the address bands of the MS protected and MNS unprotected memories.

In the example of FIG. 5, the address pointers of the protected MS and unprotected MNS memories are, respectively, BUFF_MS and BUFF_MNS.

In a preferred embodiment, the binary EXE script is contained in a work memory MT allocated by the aforementioned allocation means and indicated by the address pointer BUFF_EXE.

In the embodiment described here, the binary EXE script is, in practice, loaded into the working memory by means of loading the computer system, for example a PCI bus.

In another embodiment, the binary EXE script is stored in non-volatile memory and loaded at the time of validation.

The computer system thus comprises a validation device comprising a verifier program adapted to verify the validity of the EXE binary script.

In general, the verification program of the computer system is adapted to implement the validation procedure and the execution procedure described above with reference to Figures 3 and 4.

More precisely, the verifier program is adapted to verify that any function adapted to read data from the protected memory MS and to produce data in the unprotected memory MNS is an encryption function.

It is also adapted to verify that any data produced by a decryption function is stored in the protected memory MS.

ES 2 298 516 T3

The verifying program is adapted, in particular, to go through the binary EXE script stored in the working memory MT, to indicate the instructions corresponding to the identifiers and the arguments of the encryption, decryption and logic functions after compilation.

This signaling stage is carried out by comparing the hexadecimal data of the EXE binary script with the information contained in the TS syntax table described above referring to figure 1.

Once these identifiers and arguments have been indicated, the verifying program of the computer system is adapted to verify that the access rules memorized in the verification table TV, described above referring to figure 2, are respected.

To do this, and for each read or write operation in a memory, it indicates in the binary EXE script the memory address in which this operation should be performed.

It then determines whether this operation is scheduled to take place in the protected memory MS or in the unprotected memory MNS, this by comparing the address expected for the operation with the values ​​of the BUFF_MS and BUFF_MNS address pointers.

Once the type of these memories has been identified, the verifying program of the computer system verifies that the writing or reading operation conforms to the access rules for the type of function being processed.

In another embodiment, the validation procedure is implemented at the protected operating system level. Such an operating system can advantageously be used on a microcircuit card.

(Scheme goes to next page)

ES 2 298 516 T3

<td colspan="3">ANNEXES</td>

<td>Schedule A / ”al” /</td><td colspan="2">DES-1 (INPUT = [IN-BUF / 00/08], KEY = ”CIPHER.TEST1”, OUTPUT</td>

<td>/ ”A2” /</td><td>= [PRIVATE / 00/08]); CHEKCSUMXOR (INPUT</td><td>= [PRIVATE / 00/08]), OUTPUT =</td>

<td>/ ”A3'7</td><td colspan="2">[PRIVATE / 08/01]); DES (INPUT = [PRIVATE / 00/09], KEY = ”CIPHER.TEST1”, OUTPUT</td>

<td>Schedule B / * bl * / 006C</td><td>= [OUT_BUF / 00/10]);</td><td>/ * script size * /</td>

<td>/ * b2 * / 03</td><td></td><td>/ * number of operations * /</td>

<td>/ * b3 * / 24</td><td></td><td>/ * size instructions DES-1 * /</td>

<td>/ * b4 * / 22</td><td></td><td>/ * identifier DES-1 instructions * /</td>

<td>/ * b5 * / O3</td><td></td><td>/ * number of arguments * /</td>

<td>/ * b6 * / 01 08</td><td> 0000000000000008</td><td>/ * INPUT * /</td>

<td>/ * b7 * / 05 0C</td><td>4349504845522E5445535431</td><td>/ * KEY * /</td>

<td>/ * b8 * / 04 08</td><td> 0000000000000008</td><td>/ * OUTPUT * /</td>

<td>/ * b9 * / 16</td><td></td><td>/ * size instructions</td>

<td>/ * bl0 * / 53</td><td></td><td>CHECKSUMXOR * / / * instruction identifier</td>

<td>/ * bll * / 02</td><td></td><td>CHECKSUM XOR * / / * number of arguments * /</td>

<td>/ * bl2 * / 04 08</td><td> 0000000000000008</td><td>/ * INPUT * /</td>

<td>/ * bl3 * / 04 08</td><td> 0000000000000001</td><td>/ ♦ OUTPUT * /</td>

<td>/ * bl4 * / 24</td><td></td><td>/ * size DES instructions * /</td>

<td>/ * bl5 * / 21</td><td></td><td>/ * identifier DES-1 instruction * /</td>

<td>/ * bl6 * / 03</td><td></td><td>/ * number of arguments * /</td>

<td>/ * bl7 * / 04 08</td><td> 0000000000000009</td><td>/ * INPUT * /</td>

<td>/ * bl8 * / 05 0C</td><td>: 4349504845522E5445535431</td><td>/ * KEY * /</td>

<td>/ * bl9 * / 02 08</td><td> 0000000000000010</td><td>/ ♦ OUTPUT * /</td>

<td colspan="2">/ * b20 * / 1425283678895422</td><td>/ ♦ cryptographic signature * /</td>