Method for protecting a converted applet (CAP) file including encrypting the CAP file

A method for protecting a CAP file including one or more applets to be installed in an IC Card, includes the applets encoding into the CAP file by a CAP file provider. The method also includes the CAP file downloading into the IC Card by a CAP file issuer, and storing an installation program inside the IC Card. The installation program extracts the applets from the CAP file and installs them in the IC Card, after the downloading. The CAP file provider encrypts the CAP file into a protected CAP file to avoid the applets being extracted before the downloading. The IC Card includes a decryption circuit for decrypting the protected CAP file downloaded into the IC Card. The installation of the applet is enabled by the decryption circuit.

FIELD OF THE INVENTION

The present invention relates to a method for protecting a converted applet (CAP) file including one or more applets to be installed in an IC Card.

More particularly, the present invention relates to a method of the type described above wherein the CAP file is downloaded into the IC Card according to a predetermined protocol intended to check the CAP file.

BACKGROUND OF THE INVENTION

As may be known, a CAP file is a file including one or more applets intended to be downloaded into an IC Card. Hereinafter, a brief explanation of the steps involved in the generation of the CAP file and its downloading into the IC Card are given.

A software programmer generates a CAP file by coding one or more java applets, including at least a java class, compiling the java class into a .class file, and converting the .class file into a CAP file, intended to be downloaded into the IC Card.

The steps of coding and compiling the java applet, as well as the step of converting it into a CAP file, are executed in a conventional way, for example, through a java programming environment installed in a programming device. The device may include an editor for coding the java applets, a compiler for compiling the .class files, and a converter for converting the CAP file.

With reference toFIG. 1, the downloading of the CAP file3from a card terminal2to an IC Card1is schematically represented. The IC Card1includes a platform for executing applets, not shown because it is conventional. More particularly, the platform includes a hardware platform based on the circuitry and electric components, and a software platform, including service programs that support the execution of applets.

The software platform may include a java platform. The java platform may include an installation program4for extracting the applets from the CAP file3and for storing them in a memory portion5of the IC Card1, and a java virtual machine6for execution of the applets.

More particularly, the installation program4receives the CAP file3from the card terminal2and prepares the applets to be executed by the java virtual machine6. The java virtual machine6, substantially, is generally not aware of the CAP file3because it executes the applets already prepared for execution by the installation program4.

The downloading of the CAP file3from the terminal2to the IC Card1is executed by an authorized IC Card issuer that is responsible to release only IC Cards compliant with precise specifications. The CAP file is prepared by the software programmer, also known as a CAP file provider, and delivered by the CAP file provider to the CAP file issuer for downloading. The IC Card manufacturer may also be the CAP file provider so that the IC Card, together with a set of applets included in the corresponding CAP file, is provided by the IC Card manufacturer to the IC Card issuer.

More particularly, according to international standard specifications, for example, the 03.48 specification for the mobile word or the GlobalPlatform specification, downloading the CAP file into the IC Card must typically respect some requirements, including:1—allowing only the authorized CAP file issuer to download the CAP file3into the IC Card1;2—recognizing that data corruption occurred during I/O communication between the terminal2and the IC Card1; and3—avoiding disclosure of the CAP file3during I/O communication.

Such requirements are generally respected by introducing the following security in the communication between the terminal2and the IC Card1:1—performing a mutual authentication between the IC Card1and the IC Card issuer;2—adding an integrity control check to the CAP file3received by the IC Card1; and3—encrypting the CAP file3before transmission.

FIG. 2schematically represents the steps involved in the downloading of the CAP file3when the security described above is provided. More particularly, a secure protocol7is used by the IC Card issuer for encrypting the CAP file3in an encrypted CAP file3a, before the downloading of the CAP file3from the card terminal2to the IC Card1.

The same secure protocol7is used inside the IC Card1for decrypting the CAP file3ainto the CAP file3. The decrypted CAP file3is then processed by the installation program4, as already described with reference toFIG. 1. More particularly, the security is implemented through a transport protocol based on cryptographic keys stored in the IC Card1by the IC Card manufacturer and communicated by the IC Card manufacturer to the IC Card issuer.

Even if the above described security adds a certain protection to the CAP file3, some drawbacks still limit such protection, because, when the CAP file3is delivered by the IC Card provider to the IC Card issuer, it is subject to intercepting and copying. More particularly, an intercepted CAP file could be reverse engineered so that the corresponding code of the applets is discovered, thus resulting in damage for the IC Card provider.

In fact, especially when the IC Card manufacturer is the IC Card provider, many efforts are involved to provide the IC Card1, together with a complete set of applets included in the CAP file3. Moreover, even if the CAP file is not reverse engineered, and the code of the applets is not discovered, another problem remains because the CAP file3may be directly downloaded and installed into an IC Card different to the IC Card1provided by the IC Card manufacturer. In fact, due to the portability of the java applets, the applets included in the CAP file3can be installed substantially into any IC Card provided with a java platform, resulting also in this case in a great damage for the IC Card manufacturer.

The problem is that of providing a method for protecting the CAP file for an IC Card so that the applet included in the CAP file can be executed only into a specific IC Card provided by a specific IC Card manufacturer, avoiding a downloading and installation of the CAP file into a third party IC Card, the method also being able to prevent a reverse engineering of the CAP file intended to discover the code at the base of the applets.

SUMMARY OF THE INVENTION

The present embodiments provide encryption of a CAP file before its delivery to the IC Card issuer, and provide the IC Card platform with a decryption circuit for decrypting the encrypted CAP file and enabling installation of the applets included therein.

One aspect is directed to a method for protecting a CAP file including one or more applets to be installed in an IC Card. The applets are encoded into the CAP file by a CAP file provider, the CAP file is downloaded into the IC Card by a CAP file issuer, and an installation program, stored inside the IC Card, extracts the applets from the CAP file and installs them in the IC Card after the downloading. The CAP file provider encrypts the CAP file into a protected CAP file, to avoid the applets being extracted before the downloading. The IC Card decrypts the protected CAP file after the downloading. The installation of the applet is enabled by the decrypting.

Advantageously, after the encryption executed by the CAP file provider, the CAP file generally cannot be reverse engineered. At the same time, the IC Card issuer is able to perform the downloading step for checking that the applets are compliant with specifications, since the IC Card platform decrypts the Cap file. Advantageously, the portability of the CAP file is limited to the IC Card provided with a decryption circuit.

Further characteristics and the advantages of the method will be apparent from the following description of an embodiment thereof, made with reference to the annexed drawings, given for indicative and non-limiting purpose.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

With reference toFIG. 3, a method for protecting a CAP file3for an IC Card10is schematically represented. The IC Card10includes a java platform, (not represented because conventional). The java platform includes an installation program4, intended to extract one or more applets included inside the CAP file3and to store them into a memory portion5of the IC Card10. The java platform also includes a java virtual machine6for the execution of the applets.

More particularly, when the installation program4receives the CAP file3, it prepares the applets to be executed by the java virtual machine6. The java virtual machine6, substantially, is generally not aware of the CAP file3because it executes the applets already prepared for execution by the installation program4.

The CAP file3is prepared by a CAP file provider, coding one or more applets, compiling and converting them into the CAP file3. The CAP file provider may also be the producer of the IC Card10, hereafter indicated as an IC Card manufacturer.

The CAP file provider encrypts the CAP file3into a protected CAP file30and delivers the protected CAP file30to the CAP file issuer. The CAP file provider also provides the IC Card10with a decryption algorithm for use in a decryption circuit11to decrypt the protected CAP file30.

The protected CAP file30and the decryption circuit11for decrypting it, avoid the applets and the corresponding code being retrieved from the CAP file3. This is because the decryption of the protected CAP file30is typically allowed only to the CAP file provider, since he is aware of the decryption algorithm implemented in the decryption circuit11, and to the IC Card10, since it includes the decryption algorithm for decrypting the protected CAP file30.

Moreover, the execution of the applets are allowed only inside the IC Card10provided with the decryption algorithm, and the portability of the applets included inside the protected CAP file30is advantageously limited. In other words, even if the protected CAP file30could be downloaded inside an IC Card not provided with the decryption circuit11implementing the decryption algorithm, its execution would be denied since the protected CAP file30could not be decrypted.

The protected CAP file30is delivered from the CAP file provider to the CAP file issuer responsible for downloading it into the IC Card10according to a communication protocol between the terminal2of the CAP file issuer and the IC Card10. More particularly, the IC Card issuer provides for using a secure protocol7for encrypting the protected CAP file30into an encrypted CAP file30a, before downloading of the protected CAP file30from the card terminal2to the IC Card10. The security protocol uses cryptographic keys, stored in the IC Card10by the IC Card manufacturer and communicated by the IC Card manufacturer to the IC Card issuer.

The same secure protocol7is used inside the IC Card10for decrypting the encrypted CAP file30ainto the protected CAP file30. The CAP file3is then obtained from a decryption of the protected CAP file3, by the decryption circuit11included inside the IC Card10. The CAP file3is sent by the decryption circuit11to the installation program4, as represented inFIG. 3.

The installation program4receives the CAP file3and prepares the included applets to be executed by the java virtual machine6. Advantageously, the java virtual machine6remains aware of the CAP file3, because it executes the applets already prepared for execution by the installation program4, and the downloading steps executed by the IC Card issuer remains substantially unchanged.

More particularly, hereafter an embodiment of the method is described. A CAP file3provided by a CAP file provider is protected with encryption through a secret key Kcard, thereby obtaining a protected CAP file30. A platform of an IC Card10for receiving the protected CAP file30is equipped with the secret key Kcard used to encrypt the CAP file3. The IC Card10includes a deciphering device12for decrypting the protected CAP file30with the secret key Kcard. The deciphering device12is, for example, an additional portion of hardware of the IC Card10including the decryption circuit11.

The protected CAP file30is delivered from the CAP file provider to the CAP file issuer and downloaded from a terminal2of the CAP file issuer into the java card platform of the IC Card10. The CAP file issuer typically cannot discover the source code of the CAP file3since it receives the protected CAP file30and not the CAP file3.

The principal features are hereafter resumed. A method for protecting a CAP file3, including one or more applets to be installed in an IC Card10includes encoding the applets into the CAP file3via a CAP file provider. The CAP file provider is a device or a procedure installed in a device of the manufacturer of the IC Card or in a device of a software programmer responsible for encoding. The method also includes computing the applets and converting them into the corresponding CAP file3. The method further includes downloading the CAP file3into the IC Card10via a CAP file issuer. The CAP file issuer is a device or a procedure installed in a device used by the issuer of IC Cards that is responsible to check CAP files.

The applets are extracted from the CAP file3and installed in the IC Card10after their downloading inside the IC Card10. The CAP file provider encrypts the CAP file3into a protected CAP file30to avoid the applets being extracted before the downloading. The IC Card10includes a decryption circuit11for decrypting the protected CAP file30. The installation of the applet is enabled by the decryption circuit11.

The CAP file30is downloaded from the CAP file issuer to the IC Card10according to a predetermined protocol, including an encryption of the protected CAP file30into an encrypted CAP file30a, before downloading, and a decryption of the encrypted CAP file30ainto the protected CAP file30, after downloading. The encryption of the protected CAP file30is executed by the CAP file issuer, according to a first secret key, and the decryption of the encrypted CAP file30ais executed inside the IC Card, the first secret key being stored inside the IC Card10. The CAP file3is encrypted into the CAP file30by the CAP file provider using a second secret key. The second secret key is unknown to the CAP file issuer. The decryption circuit11decrypts the CAP file30into the CAP file3using the second secret key. The second secret key is stored by the CAP file provider in a predetermined memory portion of the IC Card10.

The present embodiments also relate to an IC Card10implementing the method for protecting the CAP file. More particularly, the IC Card10includes an installation program4for extracting and installing one or more applets included in a CAP file3. The CAP file3is being encoded by a CAP file provider and downloaded into the IC Card10by a CAP file issuer. The IC Card10includes a decryption circuit11for decrypting a protected CAP file30derived from an encryption of the CAP file3via the CAP file provider to avoid the applets being extracted before the downloading.

The decryption circuit11includes a second secret key for decrypting the protected CAP file30. The decryption circuit11also includes an algorithm installed in a memory portion of the IC Card for decrypting the protected CAP file30via the second secret key.

According to another embodiment, the decryption circuit11includes an additional device storing a second secret key for decrypting the protected CAP file30. In this embodiment, the IC Card10includes an additional portion of hardware that allows or locks the installation of applets included in a CAP file. Advantageously, detecting an IC Card10implementing the method is simple. In fact, a non-encrypted CAP file3includes a predetermined hexadecimal sequence of bytes, generally corresponding to the hexadecimal bytes “DECAFFED.” By analyzing the communication between the card terminal2and the IC Card10during the downloading of the CAP file3, it is possible to understand if the CAP file3is in plain text format. In this case, it is easy to establish that the method for protecting the CAP file is not implemented.

Similarly, it is possible to understand if the CAP file3is encrypted by the secure protocol7. When the CAP file3is encrypted into the encrypted CAP file30a, the APDU commands sent from the card terminal2to the IC Card10are changed to inform the IC Card of the encryption. For example, using the GlobalPlatform secure protocol, a CLASS byte in the data sent from the card terminal2to the IC Card10are changed from ‘80’ to ‘84’ as follows:

1) 80 xx xx xx xx xx xx xx xx DE CA FF ED

2) 84 xx xx xx xx xx xx xx xx YY YY YY YY

3) 80 xx xx xx xx xx xx xx xx YY YY YY YY

Also in this case it is generally easy to establish that the method for protecting the CAP file3is not implemented, but that a secure protocol7is implemented.

Advantageously, after the encryption executed by the CAP file provider, the protected CAP file30typically cannot be reverse engineered. At the same time, the IC Card issuer is able to perform the downloading step for checking that the applets are compliant with specifications, since the IC Card platform is provided with the decryption circuit11for decrypting the CAP file30. Advantageously, the portability of the CAP file30is allowed generally only for the IC Card10including the decryption circuit11implementing the decryption algorithm. Advantageously, the method typically does not involve the java virtual machine included in the platform of the IC Card, nor the installation program4of such IC Card, since the decryption circuit11returns a decrypted CAP file3to the installation program4. In other words, both the java virtual machine and the installation program4are unchanged.

A further advantage is that the protocol between the card terminal2and the IC Card10is not affected. More particularly, a secure protocol7, for example, the 03.48 or GlobalPlatform protocol, can be used between the card terminal2and the IC Card without modifications.

Advantageously, the method improves the security of transmission of the CAP file3. In fact, while the secure protocol cited above provides security to the I/O communication between the IC Card10and the card terminal2, the present embodiments extend the security to the communication between the CAP file provider the IC Card10.