GB2331677A - Limiting cryptographic throughput - Google Patents

Abstract

A personal data carrier (PDC) includes an integrated circuit (IC) 12 for encrypting and decrypting data at less than or equal to a pre-defined rate (e.g. such as a rate set by a governmental agency). The data throughput rate is controlled to within the pre-defined rate but without compromising the performance and efficiency of the portion of the IC which performs the cryptography (e.g. a CEU 28). Following an initial delay (Y) after resetting the IC, cryptographic operations are executed at whatever rate the IC is capable of, until a counter (32) determines that the CEU should be disabled based upon the amount of data thus far encrypted, the time it takes for execution of each operation, and the initial delay period. Preferably, the counters operate from hard-coded values (e.g. values stored in ROM) to prevent achievement of data throughput rates in excess of the pre-defined rate.

Description

METHOD FOR LIMITING CRYPTOGRAPHIC DATA THROUGHPUT

Field of the Invention

2331677 The present invention relates to cryptography in general, and more specifically to methods for limiting cryptographic data throughput.

Background of the Invention

An increased use of portable data carriers (e.g. smart cards) for electronic transactions in the financial arena has led to the need for increased levels of security to protect the integrity of the transactions.

Increased security levels are typically achieved by increasing the length of the key used to encrypt and decrypt the data transmitted. For example, a 256 bit encryption key will provide much more secure data transmission than a 128 bit encryption key because there are 2 128 more possible combinations to crack the cryptography.

While market demand is pushing an increase in security levels, some governments limit the strength of encryption keys made available on the public market. Governments are concerned that strong, publicly available encryption techniques would make it too easy to conduct illegal activities via electronic transmissions, and would make government tracing and decryption of the transmissions too difficult. Particular concern lies in exportation of cryptographic devices to persons in foreign countries. Current commercially available technology for cryptography is now capable of using 1024 bit (or longer) cryptography keys, but many governments restrict use of such keys to "Signature /Authentication" applications (i.e. electronic signatures) as used by financial institutions.

Using such strong encryption keys for "Secrecy" applications (i.e. hiding informatipn from everyone other than the sender and receiver of the information) is not in the public's interest according to some governments. However, such governmental restrictions pose a threat to the smart card industry by limiting the applications in which smart cards will be used, and by limiting the security levels within these applications.

In addition to restrictions placed upon encryption key lengths, governments are also proposing to restrict the rate at which encryption occurs. The rationale is that the longer it takes to encrypt and decrypt data, the less likely that the electronic transmission will be used to conduct or promote illegal activity or to breach national security. However, government imposed delays in cryptography threaten legitimate applications for encrypted transmissions, e.g. those used in conjunction with legitimate financial transactions.

While it is necessary to abide by whatever government restrictions are set for cryptography, it is also important to meet the market demands for faster and stronger encryption techniques. Abiding by encryption rate restrictions could slow or even halt the expansion of smart card usage in areas such as the banking industry. Consumers will demand more and more complex computations to occur within the same 24 second transaction duration, yet manufacturers will be unable to accommodate the demand due to restrictions imposed by governments in an effort to curtail illegitimate activity.

Accordingly, a need exists to comply with government imposed restrictions on cryptography rates while at the same time maximising the computational power of cryptographic devices to meet demands for more complex secured transactions which have legitimate purposes.

Brief Description of the Drawings

FIG. 1 illustrates a personal data carrier, e.g. a smart card, with an embedded integrated circuit.

FIG. 2 illustrates, in block diagram form, portions of an integrated circuit for use in a smart card in accordance with the invention.

FIG. 3 illustrates, in more detail and in a partial block diagram form, the cryptographic execution unit and controller of FIG. 2 in accordance with one embodiment of the present invention.

FIG. 4 illustrates, in a flow diagram form, a method for limiting cryptographic data throughput in accordance in the present invention.

FIGs. 5-6 illustrate, in graph form, the effect of data encryption /decryption using the method of the present invention.

Detailed Description of a Preferred Embodiment

Generally, the present invention enables limitations on the throughput of encrypted data to be imposed to a pre-set value (e.g. as set by a government agency) while at the same time maximising the cryptographic capability of the device. In a preferred embodiment, the device performing cryptography is an integrated circuit included in a personal data carrier such as a smart card. A predetermined delay is imposed after resetting the smart card. Following lapse of the initial delay, execution of cryptographic operations is enabled and the number of bits of data encrypted /decrypted and the time for executing the operations is monitored. Execution of cryptographic operations is then disabled when the encrypted /decrypted data throughput reaches a pre-set value. In one embodiment, the throughput is measured by dividing the number of bits encrypted /decrypted by the sum of length of the initial and the execution times of each cryptographic operation which has occurred since enabling such operations. Rather than measuring the actual execution times of the cryptographic operations, an embodiment of the invention uses a counter to count the number of operations executed and uses a pre-assigned time associated to the performance of an operation. By imposing an intentional delay and then monitoring the amount of data encrypted over a span of time, one is able to abide by goverrument imposed restrictions on data throughput while taking advantage of the cryptographic capability of the integrated circuit. A series of cryptographic operations can be executed together following the initial delay to maximise the performance and efficiency of the device, thereby enabling higher computational transactions to occur while complying with throughput restrictions.

These and other features, and advantages, will be more clearly understood from the following detailed description taken in conjunction with the accompanying FICs. 1-6. It is important to point out that the illustrations are not necessarily be drawn to scale, and that there are likely to be other embodiments of the present invention which are not specifically illustrated.

Referring to FIG. 1, a personal data carrier (PDQ 10, also known as a smart card or chip card, is shown with an embedded integrated circuit (IQ 12. IC 12 is shown as hidden in FIG. 1 since it is not fully visible when looking at the card. IC 12 includes memory, Input/Output (1/0 circuitry, and a microprocessor or other controller (as further explained below) to allow PDC 10 to convey or exchange potentially large amounts of information with a PDC reader or terminal device (not shown). PDC 10 is used in many applications such as banking, transportation, medical, identification, and security. For example, PDC 10 may contain the user's personal data, medical history, national identification, and/or passport. PDC 10 can store financial information such as bank account information, stock portfolio, and other investments. PDC 10 can store monetary value(s) which is automatically deducted from, including any applicable foreign exchange rates, each time the user conducts a transaction such as to pay transportation fares, purchase merchandise, or access long-distance telephone services. PDC 10 can also store security codes for access to restricted areas.

A PDC operates in either a contact mode and contactless mode. In contact mode, PDC 10 is inserted into, or swiped through, a PDC reader that makes direct electrical contact with contact pads 13 on the PDC. The PDC reader provides operating power to PDC 10 (and thus to IC 12) through the contact pads and performs the necessary read and write operations to complete the transaction. In contactless mode, a PDC is brought into the vicinity of the PDC reader which transmits an RF signal to the PDC. The PDC includes one or more RF coils (not shown in FIG. 1). wound around the perimeter of the carrier that extract operating power from the RF signal to energise the embedded IC. The information between the PDC reader and the PDC is also exchanged over the RF link, for example by holding the PDC to within a few centimetres of the PDC reader.

The PDC reader transmits an RF signal to supply operating power to the PDC which then transn-tits the user's identification and security access codes to the PDC reader. As illustrated, PDC 10 is shown to be operable in a contact mode with the presence of contact pads 13; however, the present invention is applicable to PDCs regardless of the mode of operation.

FIG. 2 illustrates, at a block level, the basic constituency of an IC 12 used in accordance with the present invention to transmit encrypted data to and from PDC 10. Operating power module 14 receives operating power in this case by direct contact with the PDC reader and contact pads 13. Operating power module 14 distributes a positive power supply potential (e.g. VDD) to the other circuitry in IC 12. A microprocessor core 16 performs the control, timing, and decision making functions of PDC 10. For example, microprocessor 16 controls the read, write and erase operations to the memory and makes data available to data 1/0 module 18. Data 1/0 module 18 sends and receives data to and from the PDC reader. In contact mode, data 1/0 module 18 makes direct electrical contact with terminals on the PDC reader to exchange information. In a contactless, mode, a data 1/0 module would interact with the PDC reader over an RF link. Security module 19 prevents unauthorised use or access of PDC 10 and routinely checks operating integrity.

Continuing with FIG. 2, Read-Only-Memory (ROM) module 20 of IC 12 stores the program instructions for the given application which are set during the manufacturing process and then executed by microprocessor core 16. ROM module 20 provides flexibility in programming the PDC for a variety of applications. A Random-Access-Memory (RAM) module 22 is also included. RAM is volatile memory and thus provides temporary storage of information. Electrically Erasable Programmable ROM (EEPROM) 24 is a non-volatile memory array of IC 12 that stores the primary information of PDC 10, such as personal identification, medical history, banking information, monetary values, security codes, etc.

depending on the application. While EEPROM is a preferred form of memory, other types of non-volatile memory can be used in place of EEPROM 24.

In accordance with the invention, IC 12 further includes a Cryptographic Execution Unit (CEU) 28 which is used to encrypt data being transferred from PDC 10 to a PDC reader and to decrypt data being transferred from the PDC read to PDC 10. The manner in which data is -6 encrypted or decrypted is not particularly important for the purposes of understanding and practising the present invention. Conventional cryptographic methods can be employed (e.g. RSA cryptography). Accordingly, a detailed explanation of such methods is omitted. Also included in IC 12 is a CEU controller 29 which enables or disables execution of CEU 28 in accordance with the invention. CEU controller 29 and its operation are explained in further detail below.

While IC 12 has been illustrated to include definitive blocks for performing particular functions, it is noted that in practice the particular functional blocks of IC 12 may in fact not be clearly identifiable as "blockson the actual manufactured IC. Furthermore the arrangement of such "blocks" on the chip are likely to not correspond to the arrangement shown. It is also noted that while IC 12 may be illustrated in the form of a single semiconductor die, the functionality described can be implemented in one or more die within the PDC. Furthermore, an IC in a PDC may include functional blocks other than those illustrated in FIG. 2, such as a charge pump. Accordingly, the figures are not intended to limit the scope of the invention unless expressly indicated otherwise.

FIG. 3 illustrates one embodiment of CEU Controller 29 in greater detail. As explained above, the overall function of the CEU Controller is to enable and disable the CEU, which thus controls the amount of data being encrypted /decrypted. The CEU Controller is thus used to achieve compliance with government regulations on cryptography throughputs. A particular embodiment of providing such throughput control is illustrated in FIG. 3. CEU Controller 28 controls a CEU Enable signal to the CEU 28. If the CEU Enable Signal is asserted, CEU 28 is permitted to act upon an EXECUTE instruction received from the microprocessor core 16 of IC 12. CEU 28 then encrypts the data being sent from the microprocessor at whatever speed or rate it is capable of performing, irrespective of any overall throughput restrictions imposed. An analogous process is used for data decryption.

The control of the encrypted /decrypted data throughput is achieved by CEU Controller 29. A description of the various components of CEU

Controller and their connectivity to one another will first be described.

1 The operation of the controller will be subsequently described in reference to FIG. 4. CEU Controller 29 includes a Delay Counter 30 and a Usage Counter 32. Delay Counter 30 receives an input from an RC Oscillator 34. Both counters are initialised by a Reset signal input. In one form of the invention, each counter is also loaded with a predetermined value, from which the counter will decrement. Selection of the loaded values are explained further below. An output of Delay Counter 30 is coupled to an input of inverter 36.

CEU Controller 29 also includes a Delay Latch 38 and a Usage Latch 40. Both of these latches receive the Reset signal as inputs. Delay Latch 38 also receives the output of inverter 36. An output of Usage Counter 32 is coupled to an additional input of Usage Latch 40 without inversion. The outputs of Delay Latch 38 and Usage Latch 40 are received as inputs by an AND Gate 42. AND Gate 42 asserts a CEU Enable signal as its output, which is received as an input of CEU 28.

The Usage Counter 32 is used to monitor the time consumed by execution of cryptographic operations by CEU 28. Accordingly it is coupled to CEU 28, in this instance via an AND Gate 44. One input to AND Gate 44 is an output from CEU 28, while a second input is the output from inverter 36. An output of AND Gate 44 is coupled to an input of Usage Counter 32 as illustrated in FIG. 3.

The operation of the CEU Controller and the CEU in accordance with the present invention will now be described. Generally, Delay Counter 30 is used to provide a predetermined time period for delaying enablement of the CEU 28 after reset of the IC 12. Thus, control by an independent clock is necessary. In a preferred embodiment, a real-time clock is used to control the delay, thus the input from RC Oscillator 34. A system clock should not be used because such a clock is generally user programmable or controllable. To assure compliance with throughput rates, the initial delay period should not be changeable after IC manufacture is complete. The Usage Counter 32 is used to monitor the time consumed by execution of cryptographic operations by CEU 28.

While one could theoretically measure the actual execution time of each operation, it is easier to assign a predetermined execution time for each 1 1 11 ---:m operation based upon the capabilities of the CEU and then simply count the number of operations executed. The latter method is that illustrated in a flow diagram 50 of FIG. 4.

The operation of the CEU 28 and the CEU Controller 29 will now be described in connection with FIG. 4, and with reference to the elements of FIG. 3. In a first step 52, the IC 12 is reset, in accordance with traditional PDC operation at the beginning of a transaction. In response to receiving a Reset signal, Delay Counter 30 and Usage Counter 32 are initialised in a next step 54. The initialisation values for the counters will be dependent upon a variety of factors, including 1) what data throughput level you are trying to comply with; and 2) how long it takes the particular CEU used to execute a cryptographic operation. An example of how one might choose such values is demonstrated below in reference to FICs. 56.

Following initialisation, the Delay Counter 30 is started in a step 56. As illustrated in FIG. 4, a decrementing counter is used, although it is understood that alternatively an incrementing counter could be used. After each decrement, a decision step 58 determines whether Delay Counter 30 has reached zero. If "No," the counter continues to decrement pursuant to time lapsed as measured by a real-time clock. If "Yes," the CEU in enabled as in step 60 of FIG. 4. In reference to FIG. 3, enabling the CEU following reset is achieved as follows. Upon reset, Delay Latch 38 will negate a Delay Complete signal to AND gate 42. Once Delay Counter 30 reaches zero, the signal will be inverted by inverter 36, causing Delay Latch 38 to assert the Delay Complete signal. AND gate 42 will then assert the CEU Enable signal because the other input to AND gate 42 is a Usage Enabled Signal which is asserted following reset until Usage Counter 32 counts down to zero.

After enabling CEU 28, data cryptography occurs pursuant to EXECUTE instructions received from the processor of IC 12. A decision step 62 determines whether the CEU has been accessed (i.e. whether it has been asked to execute a cryptographic operation). If "No," the Usage Counter 32 is put in a WAIT state (waiting for the CEU to be accessed). If "'Yes," the Usage Counter 32 is decremented (or alternatively incremented) for each operation or run executed, as indicated by a step 64. In reference to FIG. 3, a CEU Operation signal is received by AND Gate 44 and is ANDed with the output of inverter 36. Thus, if the initial delay following reset has expired and if the CEU has executed an operation, the counter is decremented. What constitutes a cryptographic operation or operation can be determined by the IC designer, being as little or as much as one wants. For example, a cryptographic operation can be as little as the performance of a modular arithmetic operation on data or as much as receiving data, encrypting it, manipulating it, and providing a response. The extent of a defined operation will govem the value of from which (or to which) the Usage Counter 32 counts. The more involved the operation, the lower the pre-set counter value needs to be.

Execution of cryptographic operations by CEU 28 is permitted to continue until the Usage Counter 32 reaches zero as determined in a decision set 66. Accordingly, the CEU can encrypt and decrypt data as fast as possible, regardless of any data throughput limits. What controls the throughput is the enabling /disabling of the CEU via, e.g., counters 30 and 32. When the Usage Counter 32 reaches zero, the CEU is disabled pursuant to a step 68. In reference to FIG. 3, disabling the CEU occurs by using the Usage Latch 40 to negate the Usage Enabled signal. Consequently, the inputs to AND Gate 42 will cause the CEU Enable signal to be negated, thus disabling further cryptographic operations until a subsequent reset and initialisation of the counters and lapse of an initial delay period as described previously and as shown in FIG. 4.

FIGs. 5 and 6 graphically illustrate an example of the time periods which may be chosen to achieve a particular data throughput rate. FIG. 6 especially demonstrates how a throughput limit can be achieved without limiting or degrading the inherent cryptographic capabilities of the IC in accordance with the present invention. For purposes of illustration only, the following assumptions are made to aid in the understanding of FIGs. 5 and 6 and the benefits of the invention. Assume that the imposed limit on encrypted /decrypted data throughput is approximately!5 2 kilo-bits of data per second (Kbits/S), and assume that the IC used in the PDC has the capability of performing one 512 bit cryptographic operation (e.g. an RSA Signature) in 80 milli-seconds (mS). In its most simplest form, the present invention can be implemented to impose a predetermined delay after each / 1, cryptographic operation as shown in FIG. 5. Following reset, an initial delay (Y) is imposed. After the lapse of delay Y, one operation is performed. The maximum number of operations executable in one second would be four (4 X 512 = 2048, about 2 Kbits). Thus, the delay associated with each operation would be 170 mS (1S/4 -8OmS = 170mS). However, the disadvantage of imposing delays as represented in FIG. 5 is that only one operation can occur at a time. Such execution is not an efficient use of the cryptographic capability of the IC, and furthermore many PDC applications require back-to-back cryptographic operations.

Moreover, such back-to-back operations are not necessarily desirable immediately following reset.

To overcome these disadvantages, the present invention is preferably implemented as shown in FIG. 6. Since the overall throughput rate continues to be fixed at,! 2 Kbits/S, the number of operations executable within a one second period remains at four. However, to enable back-toback operations and thus enable the IC to run at its own limit rather than at government imposed limit, a longer initial delay of Y = 68OmS is imposed. Following lapse of this delay after reset, the CEU can execute all four of the cryptographic operations in sequence before being disabled. In such an embodiment, the value loaded into Usage Counter upon initialisation would be 4. This value would be decremented by 1 following each operation, until eventually reaching 0 at which time the CEU is disabled until sufficient time has elapsed to perform another set of operations following another 680 mS delay.

Generally, the counter values loaded into each of Delay Counter 30 and Usage Counter 32 will be governed by the cryptographic capabilities of the IC used and the throughput limit to be achieved. To determine when to disable the CEU from further executions, take the number of bits thus far encrypted or decrypted and divide by the sum of 1) the initial delay period (Y) and 2) the sum of the execution times of each cryptographic operation executed since the CEU was last enabled. This will ensure that the maximum number of cryptographic operation can occur within a given time span and ensure that the operations occur back-to-back as may be needed by the particular application being run. Again, it is important that a user not be able to modify these values (and thus by-pass the cryptographic throughput restrictions). Accordingly, such values should be hard-coded values, such as those which can be stored in ROM.

The foregoing description and illustrations contained herein demonstrate many of the advantages associated with the present invention. In particular, it has been revealed that the invention provides a mechanism for reducing cryptographic throughput to abide by government imposed restrictions without restricting the cryptographic performance of the device. With such throughput restrictions, export administration is simplified. For instance, the time it takes to get export clearance on such a device is reduced, giving rise to a time-to- market advantage over devices without such throughput restricting capability. Administration costs are also reduced. Another advantage of the present invention is that employing a device with throughput restriction opens markets in application fields and a countries which otherwise might not be available without such throughput restrictions. And, because the throughput of a device can be tailored, use of the device in relation to any country or in any application can benefit from the invention.

Thus it is apparent that there has been provided, in accordance with the invention, a method for limiting cryptographic throughput in a device such as a PDC that fully meets the need and advantages set forth previously. Although the invention has been described and illustrated with reference to specific embodiments thereof, it is not intended that the invention be limited to these illustrative embodiments. Those skilled in the art will recognise that modifications and variations can be made while still falling within the scope of the invention. For example, the Usage Counter could be decremented (or incremented) in responses to activity other than merely cryptographic operation completion. It may be desirable to decrement the counter based upon a time lapse if the CEU is enabled but has not received instructions to execute. In addition, the invention is not limited to an implementation which uses digital counters. For instance, the invention could be practised using an RC time constant in conjunction with a threshold detector, or similar analog means. Therefore, it is intended that this invention encompass all such variations and modifications as fall within the scope of the appended claims.

Claims (10)

1. Claims
2. 2.

   1. In a data processing system, a method for limiting cryptographic data throughput, comprising the steps of: delaying execution of a cryptographic operation by the data processing system for a first predetermined period of time, enabling the data processing system to perform cryptographic operations after expiration of the first predetermined period of time; executing at least one cryptographic operation after the step of enabling, each cryptographic operation having an execution time, wherein the step of executing furthers encryption or decryption of a number of bits of data; disabling execution of cryptographic operations when a data throughput rate reaches a predetermined value, said data throughput rate being measured as- the number of bits encrypted or decrypted as result of performing said step of executing divided by the sum of the first predetermined period and the execution time of each cryptographic operation executed since the step of enabling.

   The method of claim 1 wherein prior to the step of disabling execution of cryptographic operations, the step of executing is repeated until the predetermined value of data throughput rate is reached.
3. 3. The method of claim 1 or 2 wherein the data processing system is a smart card containing an integrated circuit.
4. 4. The method of claim 3 wherein the integrated circuit includes a cryptography execution unit capable of encrypting and decrypting data at a predetermined cryptography rate, and wherein the step of executing comprises encrypting or decrypting data at the predetermined cryptography rate.
5. 13- The method of claim 3 further comprising the step of resetting the smart card, and wherein the step of delaying occurs after the step of resetting but before the step of enabling.
6. 6.The method of claim 1 or 2 wherein the step of delaying is facilitated by use of a digital counter.
7. 7. The method of claim 6 wherein the digital counter counts from or to a predetermined delay value, and wherein the predetermineded delay value is a hard-coded, fixed value which cannot be modified by a user.
8. 8. The method of claim 1 or 2 wherein the step of delaying is facilitated by use of an analog delay means.
9. 9. The method of claim 1 or 2 wherein an execution counter counts the number of cryptographic operations executed, and wherein the step of disabling occurs when the execution counter reaches a predetermined disable trigger value.
10. 10. The method of claim 9 wherein the predetermined disable trigger value is a hard-coded, fixed value which cannot be modified by a user.