EP1278164B1 - System and method for changing the functionality of a security module - Google Patents

Description

The invention relates to an arrangement for changing the functionality of a security module, specified according to claim 1 type and a corresponding method, according to claim 3 specified type. Security modules operates in a potentially unfriendly environment in ATMs, ticket vending machines, cash registers, electronic purses, computers for the personal use (palmtops, notebooks, organizers), cell phones and devices that combine several of these features. The modules are encapsulated with a potting compound. In the form of a postal security module is an insert in a postage meter or mail processing machine or computer with post-processing function (PC meter) possible.

It is already out EP 417 447 B1 It is known to use special modules in electronic data processing systems and equip them with means for protection against a break-in in their electronics. Such modules are among the security modules.

Modern franking machines, or other devices for franking mail, are provided with a printer for printing the postage stamp on the mail, with a controller for controlling the printing and peripheral components of the postage meter, with a bill unit for settling postage paid in nonvolatile memories and a unit for cryptographically securing postage data. A security module ( EP 789 333 A2 ) may include a hardware canceling unit and / or the unit for securing the printing of postal fee data. For example, the former can be realized as a user circuit ASIC and the latter as an OTP processor (One Time Programmable). An internal OTP memory stores read-only sensitive data (cryptographic keys), which are required, for example, to reload a credit. An encapsulation by a safety housing provides further protection.

In order to protect a security module from an attack on the data stored in it, further measures have been proposed in which DE 198 16 572 A1 entitled: Arrangement of a security module and DE 198 16 571 A1 with the title: Arrangement for Security Module Security, im EP 1 035 516 A2 entitled: Arrangement of a security module, im EP 1 035 517 A2 and EP 1 035 518 A2 both entitled: Method of Protecting a Security Module and Arrangement for Carrying out the Method, in EP 1 035 513 A2 with the title: Security module with status signaling, as well as in the German utility model DE 200 20 635 U1 , entitled: Arrangement for supplying power to a security area of a device.

The various techniques used hitherto, such as the enclosure with a secure housing and the use of various event detectors, which possibly cause the security module to delete security-relevant data ( EP 1 035 518 A2 and DE 200 20 635 U1 ) can provide secure protection against manipulation only for the intended application functionality.

From the US 4,528,644 A method of customizing the firmware of an electronic postage meter after assembly thereof is known, wherein an input of a configuration message is stored in a nonvolatile memory and cooperates with the operating program to customize the postage meter to customer preference. After completing the configuration, further access to the configuration program is prevented. However, outside the manufacturer's safe environment, it is difficult to provide secure protection against tampering. Therefore, outside the secure environment at the manufacturer, no safety-relevant program data is installed in franking machines in order to achieve a different application functionality.

In modern postal devices so-called flash EEPROMs are already being used as program memories. The latter allow for sector-by-sector deletion and saving of data as well as byte-by-byte insertion of individual data into a memory area (sector). So was already in the EP 724 141 B1 proposed a method for data input to a scale, wherein the respective memory areas are deleted in the flash EEPROM of the balance before re-programming is made, for example, to at least partially change a postage rate table. The preferably via modem of a postage meter, such as JetMail®, loaded data are stored in the flash EEPROM compressed and decompressed before use and stored in a separate application memory. The scale also provides programmable security means to prevent unauthorized erasure of data blocks in the flash EEPROM memory areas. For the franking machine, partial image files and a control file are determined, which are downloaded simultaneously with the data intended for the balance from a data center into the memory of the franking machine. In addition to a data record that also contains version information, the processing status is also saved in order to non-volatile preserve the program state achieved when the program is aborted. However, neither in the postage meter nor in the scale are scherheitsrelevante program data installed.

An electronic device with flash memory and a method of reprogramming the flash memory has been incorporated in the EP 788 115 A2 proposed. The programming of the flash program memory module is carried out by the processing of a part program contained for this purpose in a memory bank of this block, wherein the respective memory areas of the other memory bank are deleted before reprogramming is performed. In most cases, the program is longer or shorter than the free memory sector created by deletion, which therefore can not be fully exploited. In addition to the above limitation on the full use of memory space, such a device is even more expensive than a comparable one without multiple memory banks. Checking a checksum determines if reprogramming is complete. However, it can not be ruled out that the device has been reprogrammed with manipulated data.

• Programmierung eines Programm-Bausteins durch einen Programmieradapter vor dem Einbau in das Sicherheitsmodul,
• Programmierung des Programm-Bausteins durch die Abarbeitung eines für diesen Zweck in einer Speicher-Bank dieses Programm-Bausteins enthaltenen Teil-Programms.

Reprogrammable memory modules (FLASH or EEPROM) are also used in the postal security modules for function-specific program storage. The programming of these components can be carried out in a known manner according to different methods at the manufacturer:

• Programming of a program module by a programming adapter before installation in the security module,
• Programming of the program module by the execution of a part program contained for this purpose in a memory bank of this program block.

The first method has the disadvantage over the second method that a faulty program can no longer be exchanged. The second method adversely requires a device that has at least two different memory banks, which makes it more expensive in the above-mentioned severe restrictions on the use of memory space. The postal security modules are subject to special requirements with regard to the exchange or extensibility of functions. The programming of the above-mentioned program blocks may not be carried out at any time and in particular not by every operator.

From the publication EP 1087294 A2 is already known communication device with a flash memory, which has two partitions for storing a program and firmware reloading is used.

Also known is a FLASH type having only one partition, such as the Spansion ™ 16Mbit MBM29LV160TE offered by Advanced Micro Devices (AMD) or by Fujitsu, which is reprogrammable and has free space.

The invention has for its object, with little effort to meet the above-mentioned special requirements, while avoiding the disadvantages, and to provide an arrangement and method for a security module that ensures a replacement of the functionality state-dependent and authorized.

The object is achieved with the features of the arrangement according to claim 1 and with the features of the method according to claim 3.

The developed security module uses a microprocessor, which enables the execution of its program in a main memory. In addition to this main memory, a FLASH program memory is also used for the application-specific program. Both memories are connected to the processor via the bus.

1. a) Das Kopieren eines Programmteils des Startladeprogramms in den Arbeitsspeicher,
2. b) Das Ausführen dieses Programmteils im Arbeitsspeicher, zum Programmieren des freien Teils des Programmspeichers,
3. c) Das Verifizieren eines beim Programmieren erreichten Programmzustandes, um die Programmfunktionalität zustandsabhängig ausführen zu können,
4. d) Das Autorisieren der geänderten Funktionsweise des nachgeladenen Programms bei dessen Authentizität.

At the time of manufacture of the security module, a so-called "boot loader" is introduced into the program memory as a boot loader according to the first known method mentioned above. A special functionality to change the functionality of the remaining free program memory allows:

1. a) copying a program part of the boot loader into the main memory,
2. b) The execution of this program part in the main memory, for programming the free part of the program memory,
3. c) verifying a program state achieved during programming in order to be able to execute the program functionality condition-dependent,
4. d) Authorizing the changed functionality of the reloaded program with its authenticity.

The security module is thus programmed with program data during its production and receives an identifier for a first basic state. After switching on, a first program part from the memory area of the program memory is copied into the main memory by means of a startup program. The achieved program state is verified in order to be able to execute the program functionality condition-dependent. A state variable for the achieved program state can be stored, for example, in the program memory or in a non-volatile memory of the security module. A light emitting diode (LED) signals that the microprocessor is processing a second part of the program and waiting for the change of the program functionality of the free program memory. The communication interface contained in the security module at least loads application program data into a free or inactive memory area of the program memory. In addition, associated identifier data and a cryptographic signature of the application program are loaded into a non-volatile memory of the security module or also into one and the same or other free or non-active memory area of the same program memory. For this purpose, the microprocessor controlled by the second program part first verifies the identifier of the previously stored program. The identifier describes the properties of the program data and is stored in a memory location with a specific address. If the identifier stored at this address constitutes a valid predecessor of the identifier of the new application program data, the functionality of the first program component copied into the main memory is used to load the application program data received via the communication interface into the free memory area of the program memory. Before each programming of the program memory, it is additionally ensured that no data can get into the currently active bootloader memory area in order to prevent an overwriting of the boot loader. After all application program data has been stored in the free memory area of the program memory in this way, the application of authenticity of the application is released. For example, a certificate code, preferably the cryptographic signature of the loaded application program data, is verified and, if successful, the loaded application program is flagged as valid by a flag, or the acquired state of the application program is updated in another suitable manner. In addition, the associated identifier is stored. The Modification of the functionality is thus completed. After the security module has been rebooted, the boot loader now determines that the new program state is displaying valid application program functionality and is now executing it. This is additionally indicated by a different colored LED. A change in the current functionality of the program memory is no longer possible as long as the program state is not suitably modified again.

To further ensure this change in program functionality, any reloaded functionality also includes a subprogram for copying and executing programming instructions into memory. This functionality can also be called via the communication interface located in the safety module. When called, it changes the state variable such that, although the program identifier is preserved, the next time the bootloader is booted it is indicated that the application-specific software is now again a free program memory area. As a result, the next time you boot the bootloader will be active again and receive application program data.

The invention further assumes that a security module is created by means of a fast microprocessor and other partially known functional units that meets all requirements. The fast processor enables symmetric and / or asymmetric encryption for different applications. Depending on the respective application, a real-time processing of events and a recording or booking is possible. An internal battery of the safety module takes over the power supply for a real-time clock and components for non-volatile storage of user data, for permanent monitoring of all safety-related functions and the operational readiness of the safety module when the system voltage is switched off. In the case of an error and when the security module is removed, a change of state is stored in a queryable manner. The status of the security module can also be queried by the device after it has been deleted. For signaling the state, an existing display unit of the device or a signaling means of the security module can be shared.

Figur 1,

Blockschaltbild des Sicherheitsmoduls,

Figur 2,

Darstellung der Mehrschicht-Programm Architektur,

Figur 3,

Flußplan zur Änderung der Funktionalität des Sicherheitsmoduls.

Advantageous developments of the invention are characterized in the subclaims or are presented in more detail below together with the description of the preferred embodiment of the invention with reference to FIGS. Show it:

FIG. 1,

Block diagram of the security module,

FIG. 2,

Presentation of the multi-layer program architecture,

FIG. 3,

Flow chart for changing the functionality of the security module.

• einen Mikroprozessor 120 mit interner Echtzeituhr,
• einen Programmspeicher 128, zum Beispiel ein FLASH 512K x32,
• einen Arbeitsspeicher SRAM 121, zum Beispiel ein SRAM 64K x32,
• zwei nichtflüchtige Speicher NVRAM I & NVRAM II,
• einen Arbeitsspeicher SRDI-RAM 122 (Secure Relevant Data Items) mit Lösch-Hardware und BUS-Treibereinheit 127,
• eine Langzeit-Batterie 134, zum Beispiel eine Lithium-Batterie,
• eine Leistungsverwaltungs-& Überwachungseinheit (Power Manager) 11 mit Spannungsüberwachungseinheit 12, mit Schnittstellen zur Zuführung der Systemspannung (Main Power Supply Interface) und zur Batteriespannungszuführung (Host Battery Interface),
• Ereignisdetektoren(Event Detectors), einschließlich einer Zerstörungs-Detektionseinheit 15, die mit einer in einer Vergussmasse 105 eingebetten Membrane 153 verbunden ist, und einer Ungestecktsein-Detektionseinheit 13,
• einen speziellen Schaltkreis FPGA 160 mit einem I/O Interface 150 zur Herstellung einer Kommunikationsverbindung mit einem Gerät. Das Kommunikationsinterface 150 enthält eine interne Steuerung und einen 8 Byte-Kommunikations-Puffer, aus welchem zuerst eingelesene Daten zuerst ausgelesen und weitergeleitet werden.

The FIG. 1 shows a block diagram of the security module comprising the assemblies:

• a microprocessor 120 with internal real time clock,
• a program memory 128, for example a FLASH 512K x32,
• a memory SRAM 121, for example a SRAM 64K x32,
• two non-volatile memories NVRAM I & NVRAM II,
• a memory SRDI-RAM 122 (Secure Relevant Data Items) with erase hardware and BUS driver unit 127,
• a long-term battery 134, for example a lithium battery,
• a power management & monitoring unit (Power Manager) 11 with voltage monitoring unit 12, with interfaces for supplying the system voltage (Main Power Supply Interface) and for the battery voltage supply (Host Battery Interface),
• Event detectors, including a destruction detection unit 15 connected to a diaphragm 153 buried in a potting compound 105, and an unplugged detection unit 13;
• a special circuit FPGA 160 with an I / O interface 150 for establishing a communication connection with a device. The communication interface 150 includes an internal controller and an 8-byte communication buffer from which first read-in data is first read out and forwarded.

The manufacturer device provides a system voltage and optionally a second battery voltage. The safety module is operated with system voltage when the manufacturer device is switched on. To change functionality, the security module 100 is equipped with a reprogrammable FLash program memory 128 that stores a boot loader and a microprocessor 120 that partially copies the boot loader into the main memory SRAM 121. The integrated communication interface 150 of the special circuit 160 enables the establishment of a communication link with the manufacturer device, which provides application program data for the security module. The microprocessor 120 communicates via a BUS with the main memory SRAM 121, with the FLASH program memory 128 and with the communication interface 150 in a communicative connection. It is provided that the communication interface 150 is designed to provide data for at least part of an application program, an associated certificate code and identification data, and that the microprocessor 120 is programmed by the start-up program partially copied into the main memory 121, the data of the part of the application program being on one to store free memory space of the FLASH program memory when the identifier data mark a successor to the stored preceding identifier, and to verify the authenticity of the loaded at least a part of the application program by means of the certificate code and to store the authenticity of the loaded part of the application program the latter as valid.

The microprocessor 120 determines whether the tag data identifies a successor to the stored header tag by comparing the tag data with corresponding comparison data stored in another memory area of the FLASH program memory 128 in which information data about an already loaded program is listed. Tag data includes program type, version and revision data. Advantageously, a microprocessor type is provided which allows the execution of its program in a working memory 121 to re-program the FLASH. This eliminates the need for an expensive FLASH program memory device with separate memory banks.

The power management unit (Power Manager) 11 has a plurality of functional units, which ensure the operability of the security module with a low power consumption even when the device is switched off. The power management unit 11 includes a DC / DC converter (not shown) and a voltage regulator (not shown) for the respective operating voltages (3V, 5V and 8V), a temperature and voltage monitoring circuit (not shown). The latter two can generate a reset signal. The supplied system voltage is monitored for exceeding or falling below of limit values. Within the latter, a DC / DC converter provides for a predetermined operating voltage U _B. Voltage generation ensures the generation of all necessary voltages required by the functional units of the safety module.

When the device is turned off, only one real-time clock RTC and the main memory are supplied with battery voltage in addition to the monitoring circuits and the destruction detection unit. An uninterrupted supply of battery operated units is also available DE 200 20 635 U1 communicated. The latter includes at least one of the post memories, some of the detectors and the SRDI memory. Two independent batteries can be connected to the safety module. The first battery voltage comes from the internal battery 134, which may optionally be supported by a second separate battery.

As an alternative to the internal real-time clock, a separate real-time clock RTC 124 can be connected. For example, the microprocessor 120 is of the ARM7 type and the separate real-time clock is of the EPSON RTC-4543 type. The microprocessor 120 is connected via a BUS to the program memory FLASH 128, the main memory SRAM 121, the main memory SRDI-RAM 122 and the special circuit FPGA 160. The bus is shown with wide white arrows. The special circuit FPGA 160 is a user-specific programmed FPGA (one time programmable). The FPGA contains a hardware billing unit (not shown), a drive circuit for two further memories NVRAM I and II and an I / O interface (digital interface of the Security module not shown) to the device (not shown). The special circuit FPGA 160 is connected to two nonvolatile memories 114 (NVRAM I) & 116 (NVRAM II) which contain, among other things, the postal relevant data. The two nonvolatile memories NVRAM I and II are physically separated and implemented in different technologies. They can be addressed by the processor in writing and reading, can be modified by the FPGA and can be read from outside the security module. One of the nonvolatile memories is implemented in a mixed EEPROM SRAM technology, the other is a conventional technology SRAM.

The supply of the system voltage (Main Power Supply Interface) and the battery voltages to the interface has been marked with wide black arrows. Thin black arrows indicate the supply of components with a corresponding operating voltage from the power management and monitoring unit 11 or from the monitoring unit 12. Thin white arrows indicate interrogation and control lines.

The erase hardware includes power management & monitoring unit means, a control line CL, and a bus driver unit 127 in part. The control lines from the destruction detection unit 15 and the voltage monitoring unit 12 are connected to a common control line CL, shown in phantom. The units 12 or 15 control via the common control line CL to an electronic switch S, which selectively applies operating voltage U _B or erase voltage U _C or ground potential U _M to the VCC pin of the SRDI memory 122. This SRDI RAM is not directly connected to the processor bus. All digital signals are routed via driver circuits of the bus driver unit 127, which have outputs that can be switched to high impedance. Thus, the BUS can be decoupled from the SRDI memory 122. The bus driver unit 127 is also driven by the common control line CL.

• Spannungsüberwachungseinheit 12, die zur Batteriespannungsüberwachung mit Selbsthaltung ausgebildet ist,
• Zerstörungsdetektionseinheit 15 zur Detektion gegen mechanische Zerstörung des Sicherheitsmoduls mit Selbsthaltung,
• Ungestecktsein-Detektioneinheit 13 (Host-System-Loop) mit Selbsthaltung.
• Temperatursensor und weitere
• Spannungsüberwachungseinheiten zur Überwachung aller Spannungen im System, insbesondere der Systemspannung.

The following detector and monitoring units monitor the proper operation of the safety module:

• Voltage monitoring unit 12, which is designed for battery voltage monitoring with latching,
• Destruction detection unit 15 for detection against mechanical destruction of the safety module with latching,
• Disconnected detection unit 13 (host system loop) with latching.
• Temperature sensor and more
• Voltage monitoring units for monitoring all voltages in the system, in particular the system voltage.

The first two cause the data in the SRDI memory to be cleared when triggered (or linked).

The third detector can only cause a state change and be interrogated by the processor during operation or at system startup by the program of the security module.

The temperature sensor monitors the operating temperature of the module and triggers a reset if the temperature drops below or above a predetermined value. This also prevents improper use and protects the user data. A reset will also be triggered if the input voltage of the module becomes too low or too high, or if the internal operating voltage drops below a certain level. The status of all other voltages can be queried by the system software. The security module contains - not shown - LED for status output and is potted with a hard, opaque potting compound 105, in which a sensor diaphragm 153 is embedded. One of the event detectors, the destruction detection unit 15, is connected to conductor loops of the sensor diaphragm 153.

The FIG. 2 shows a representation of the multi-layer program architecture. The top layer contains a pre-initialization program and an application program. The pre-initialization program, after the hardware of the security module has been manufactured, is established via a manufacturer application program load interface (Manufacturing Application Programming Interface) and causes the generation of a public key pair, which creates a unique identity. The latter enables a recognition of the security module at any time. The initial cryptographically unique identity can later be replaced by the customer's cryptographic identity. The application program determines the regular functionality during the operation of the security module. It is available through a Operational Application Programming Interface (Operational Application Programming Interface) and may, for example, comply with PKCS # 11 or some other cryptographic standard.

In the middle layer is an open Secure Socket Layer Library, which the layers above (Pre Initializer & Application Software) can use. The collection (OpenSSL Library) contains a large number of sets of cryptographic algorithms (DES, triple-DES, RSA, DAS, SHA-1, HMAC, etc.) and such PKCS and ASN.1 formatting tools as the X.509v3 certification standard. The OpenSSL Library also includes a small and efficient collection of Elliptic Curve Digital Signature Algorithms (ECDSA), which allows selection of one or more different elliptic curves recommended by the NIST.

The bottom layer contains a boot loader with an integrated code checker. The boot loader first loads the pre-initialization program which once loaded and executed, can not be replaced by another pre-initialization program, but at most by a part of the application program. Before the bootstrap program stores the state of a loaded part of the application program as valid, the latter is checked by means of a certificate code. The certificate code is provided with each part of the application program. For verification, a code verification key is needed, which is loaded during production as part of a pre-initialization.

From the data of the application program, a hash value is formed, which is encrypted, for example, with a key according to the known DES method (Data Encryption Standard) to a Message Authorization Code (MAC). The MAC is attached as a certificate code to the application program. However, the code verification key must be stored in the security module in a read-only manner if the code verification key is a key of a symmetric encryption method (DES).

1. [1] American National Standards Institute: Public Key Infrastructure-Practices and Policy Framework; ANSI X9.79, 2000
2. [2] ISO/CCITT Directory Convergence Document: The Directory - Authentication Framework; CCITT Recommendation X.509 and ISO 9594-8, "Information Processing Systems - Open Systems Interconnection - the Directory-Authentication Framework".
3. [3] ISO_9594-8a 95 ISO/IEC 9594-8: Information technology - Open Systems Interconnection - Specification - The Directory: Authentication framework; ISO/IEC International Standard, Second edition 15.09.1995.
4. [4] ISO_10181-2 96 ISO/IEC 10181-2: Information technology - Open Systems Interconnection - Security frameworks for open systems: Authentication framework; ISO International Standard 10181-2, Ist edition, 96.05.15, 1996.
5. [5] Bruce Schneier: Applied Cryptography: Protocols, Algorithms, and Source Code in C; (2nd ed.) John Wiley & Sons, New York 1996, Chapter 24.9
6. [6] Simson Garfinkel, Gene Spafford: Web Security & Commerce (Section III Digital Certificates; O'Reilly & Associates, Cambridge 1997 .

Read-only saving is eliminated when a public code verification key is loaded. Preferably, it is provided that the code verification key is a public verification key, that the public verification key and a corresponding secret signing key form a key pair, and that the certificate code is generated by means of the secret signing key from the manufacturer associated with the data of at least part of an application program. For this purpose, a hash value is formed from the data of the application program, which is encrypted, for example, with a secret signing key according to the known RSA method (Rivest, Shamir and Adleman) to form a digital signature. The code verification key is generated, stored, and authenticated by a trusted hub of the manufacturer, using a global public key infrastructure. The following standards exist for the public key infrastructure used:

1. [1] American National Standards Institute: Public Key Infrastructure Practices and Policy Framework; ANSI X9.79, 2000
2. [2] ISO / CCITT Directory Convergence Document: The Directory - Authentication Framework; CCITT Recommendation X.509 and ISO 9594-8, "Information Processing Systems - Open Systems Interconnection - the Directory-Authentication Framework".
3. [3] ISO_9594-8a 95 ISO / IEC 9594-8: Information technology - Open Systems Interconnection - Specification - The Directory: Authentication framework; ISO / IEC international standard, second edition 15.09.1995.
4. [4] ISO_10181-2 96 ISO / IEC 10181-2: Information technology - Open Systems Interconnection - Security frameworks for open systems: Authentication framework; ISO International Standard 10181-2, is edition, 96.05.15, 1996.
5. [5] Bruce Schneier: Applied Cryptography: Protocols, Algorithms, and Source Code in C; (2nd ed.) John Wiley & Sons, New York 1996, Chapter 24.9
6. [6] Simson Garfinkel, Gene Spafford: Web Security & Commerce (Section III Digital Certificates, O'Reilly & Associates, Cambridge 1997 ,

In the FIG. 3 A flow chart for changing the functionality of the security module is shown.

After switching on a - not shown - manufacturer device energy is provided and in step 200, it is checked whether the power had the intended success, so that applied to the security module, a system voltage. If not, then a waiting loop is branched and the query is repeated continuously. If the system voltage is applied to the safety module, a startup program is started in step 201 and at least a first part of the boot loader program with the programming functionality is copied into the main memory SRAM 121. The microprocessor 120 is programmed by the boot loader program that the memory area of the FLASH program memory in which the boot loader is located can only be copied but not overwritten. Information about an already loaded application program may be stored nonvolatile in another memory area of the FLASH program memory 128 or elsewhere. The information includes a state variable. In the subsequent program execution, the microprocessor determines in step 202 on the basis of the aforementioned information whether a valid state of an application program is present.

If the latter is the case, then in step 209 the application program is started. Subsequently, it is constantly checked in step 210 whether there are data for deleting the application program in the communication interface. If this is not the case, then branch back to step 209 and start the application program. Otherwise, a branch is made from step 210 to a step 211, in which the existing application program is identified as 'invalid' by means of a state variable.

On the next boot, the boot loader will be active again and can save new application program data.

First, the microprocessor determines in step 202 that the existing application program has been marked as 'invalid' or that there is no valid state of the application program, then branching from step 202 to step 203, in which a second part of the boot loader with a communication interface call and Checking functionality is started. In a subsequent query step 204, it is checked whether application program data and identification data are present in the communication interface. If this is not the case, then the system branches to a waiting loop and repeats the query. If the latter is the case, however, then a query step 205 is branched in which it is checked whether the identification data identifies a successor to the stored predecessor. The microprocessor compares the supplied identification data with stored identification data. The latter can be stored in the aforementioned further memory area of the FLASH program memory in which all information about an already loaded program is listed. The manufacturer also provides the communication interface with information data associated with the application program data, such as the start and end address of the program, checksum (CRC), program type, version, revision. Tag data includes program type, version and revision data.

If the identifier data present in the communication interface does not relate to a successor to the stored predecessor, then a waiting loop is branched back to step 204. If the in the Communication interface present identifier data mark a successor to the stored predecessor, then a branch is made to a step 206. The microprocessor is controlled according to the above-mentioned first part program of the boot loader with the programming functionality. The copied application program data is stored in a memory space of the program memory intended for the application program.

A certificate of authenticity associated with the application program, for example a cryptographic signature, is used in the subsequent query step 207 to check the authenticity of the application program. However, if no authenticity, then the query step 204 is branched back. A true application program causes subsequent validation 208 to store non-volatile information about a valid state and then branch back to query step 204. In the case of authenticity of the loaded program part which includes at least a part of the application program, for example, a state variable is stored in the nonvolatile memory of the security module or transferred to the o.g. further memory space for information data is written, which marks the aforementioned loaded program part as valid. Preferably, the state variable is a flag that marks the loaded application program as valid after verifying a cryptographic signature that proves the authenticity of the loaded application program.

New valid program data whose associated identifier data characterize a successor are only written to a memory location if the already existing program was previously marked in step 211 with the status variable 'invalid'. The latter implies that there are data for deleting the application program in the communication interface (step 210).

Due to the thus possible change in its functionality, the security module is adaptable to different devices and can be used to solve a variety of tasks.

The security module, which is intended for use in postal devices, in particular for use in a franking machine, is referred to as a postal security module (Postal Security Device) or as a secure accounting device (Security Accounting Device). A PSD is based on the same hardware as an SAD. The PSD uses an asymmetric encryption algorithm (RSA, ECDSA), but the SAD uses a symmetric encryption algorithm (DES, triple-DES). The security module may also have another design that allows it to operate in different devices. Thus, it is possible that it can be plugged, for example, on the motherboard of a personal computer, which drives a commercial printer as a PC meter.

The invention is not limited to the present embodiment, since obviously other other arrangements or embodiments of the invention can be developed or used, which - based on the same basic idea of the invention - are encompassed by the attached claims.

Claims (13)

1. An arrangement for changing the functionality of a security module having a microprocessor (120) and a reprogrammable program memory (128) that stores a start loading program that is in part copyable into a working memory (121), wherein the reprogrammable program memory (128) has a free memory space for a subsequently loadable application program in which a current application program is stored, wherein the security module has a special circuit (160) equipped with a communication interface (150) for establishing a communication connection with a manufacturer unit providing a system voltage and application program data for the security module, the microprocessor (120) being, via a BUS, in a communicative connection with the working memory (121), with the program memory (128) and with a communication interface (150), characterized in that the communication interface (150) is designed for providing data of at least part of an application program, of a related certificate code and identification data and that the microprocessor (120) is programmed by the start loading program partially copied into a working memory (121) to

   - verify the program status of the current application program on the basis of a status variable and verify its identification data,

   - store the data of the provided part of the subsequently loadable application program in the memory space of the program memory (128) free for the subsequently loadable application program when the status variable marks the program status of the current application program as invalid and the identification data of the at least one part of the modified application program loaded mark a successor to the stored previous identification,

   - check the authenticity of the at least one part loaded of the subsequently loadable application program by means of the certificate code and, in case of authenticity of the loaded part of the subsequently loadable application program, store the latter with the status variable as valid.
2. An arrangement according to Claim 1, characterized in that the program memory (128) is a FLASH-type program memory, that the communication interface (150) includes an internal control and a communication buffer from which data read in first are read out and forwarded first and that there is provided a microprocessor type that allows the execution of its program in a working memory (121).
3. A method for changing the functionality of a security module the program memory (128) of which is reprogrammable and has a free memory space for a subsequently loadable application program in which a current application program is stored, wherein the functionality is changed by reprogramming the program memory using a start load program stored in the program memory copied in part into a working memory for execution of a part of the program, characterized by the following steps:

   - execution of a program part partially copied into a working memory,

   - verification of a program status of the current application program reached by programming on the basis of a status variable, wherein the program status is stored in a non-volatile manner for being able to execute the program functionality in a status-dependent manner, and verification of the identification data of the current application program;

   - storing of the data of the part of the subsequently loadable application program in the memory space of the program memory (128) free for an application program when the status variable marks the program status of the current application program as invalid and when the identification data of the loaded at least one part of the subsequently loadable application program mark a successor to the stored previous identification,

   - authorization of the changed mode of functioning of the reloaded part of the subsequently loadable application program when it is authentic and storage of the loaded part of the new application program as valid when it is authentic and storage of the status variable.
4. A method according to Claim 3, characterized in that data of at least part of an application program, a related certification code and related identification data are provided in a communication interface (150), and that the data of the at least one part of the application program are stored in a free memory space of the program memory when the identification data mark a successor to the stored predecessor identification, and that the authenticity of the loaded at least one part of the application program is checked by means of the certificate code, wherein the latter is stored as valid when the loaded at least one part of the application program is authentic.
5. A method according to Claim 4, characterized in that, when the at least one part of the application program loaded is authentic, there is stored a status variable marking the above-mentioned loaded program part as valid.
6. A method according to Claim 3, characterized in that there is provided a code verification key for verifying the authenticity of the part of the application program loaded.
7. A method according to Claim 6, characterized in that the provision includes a loading of the code verification key that is loaded in the course of manufacturing within the scope of a pre-initialization, that the code verification key is stored in the security module in a readout-proof manner and is a secret key of a symmetrical encoding method.
8. A method according to Claim 6, characterized in that the provision includes a loading of the code verification key that is loaded in the course of manufacturing within the scope of a pre-initialization, that the code verification key a public verification key, that the public verification key and a related secret signing key form a key pair, wherein the certificate code is generated by the manufacturer with the help of the secret signing key assigned to the data of the at least one part of an application program.
9. A method according to Claim 4, characterized in that the microprocessor (120) determines whether the identification data mark a successor to the predecessor identification stored by comparing the identification data with respective reference data stored in a further memory area of the program memory (128) in which information data for an already loaded program are enlisted.
10. A method according to Claim 9, characterized in that the information data are delivered by the manufacturer related to the application program data to the communication interface (150), said information data comprising the start and end address of the program, the checksum (CRC) and identification data.
11. A method according to Claims 9 to 10, characterized in that the identification data include program type, version and revision data.
12. A method according to Claims 3 to 5, characterized in that the status variable required for the verification of a program status reached upon programming is available stored in the program memory (128) or in a non-volatile memory of the security module.
13. A method according to Claim 12, characterized in that the status variable is a flag by which the application program loaded is marked as valid after a cryptographic signature proving the authenticity of the application program loaded has been verified.

Images