WO2001097441A2

WO2001097441A2 - Method, systems and computer program for reducing hacking susceptibility

Info

Publication number: WO2001097441A2
Application number: PCT/EP2001/006668
Authority: WO
Inventors: Wayne Roger Hucaby
Original assignee: International Business Machines Corporation; Ibm United Kingdom Limited
Priority date: 2000-06-16
Filing date: 2001-06-13
Publication date: 2001-12-20
Also published as: MY136255A; AU2001276363A1; WO2001097441A3; CA2405613A1; EP1290822A2

Abstract

Method and system for reducing the susceptibility of hacking a private key of a private/public key pair. The private/public key pair is generated or place inside secure hardware inside a fiscal printer at the time of manufacture. The public key is sent to all 'need to know' users. The secure hardware has algorithms that determine the viability of a generated private/public key pair by analyzing inputted parametric data comprising technology advances, length of time a key pair has been in existence, economic factors, security value of protected data, etc. Key pairs are continuously tested and updated. Also disclosed is a method and system for erasing a generated private key if the secure hardware of a fiscal printer is tampered with or entered in an unauthorized manner.

Description

METHOD, SYSTEMS AND COMPUTER PROGRAM FOR REDUCING HACKING SUSCEPTIBILITY

TECHNICAL FIELD

The present invention relates in general to data processing systems, and in particular, to fiscal printers that contain hardware for collecting and storing information used for tax collection purposes.

BACKGROUND INFORMATION

In certain countries, point-of-sale terminal (cash register) printers must have additional hardware that collects and stores that cash register's sales totals data for reporting to the government, for tax collection purposes. These printers are known as "fiscal printers". The additional hardware in the fiscal printer that collects and stores these totals is tamper-evident (has features which show tampering) , which is accepted by these governments as "secure". This secure hardware controls print requests to the customer receipt print station from the terminal's application program, and it also generates printing itself, based on certain circumstances. All printing on customer receipts is also either printed on a separate "journal" paper roll, or stored electronically inside the secure hardware.

When an "electronic" journal or report is to be sent outside the secure hardware, it has an "electronic signature" attached to it. This electronic signature is generated via the "private/public key" method, such as that developed by the company RSA Data Security. Key pairs must be generated, so that a signature created by a private key may be authenticated with the corresponding public key. The private key resides in the secure hardware of the fiscal printer; the public key may be made known to anyone. The key pair may be entered into the printer's secure hardware module by someone trusted by the government or the keys can be generated by the printer's secure hardware itself. The advantage of the latter approach is that the private key is truly private - no one knows that key outside the secure hardware, without it being obvious that the printer has been tampered with. Also, since the secure hardware controls all printing, the public key can be printed on the receipt printer as a trusted method of revealing the public key for use in signature authentication. Any encryption algorithm's private key can be determined by employing enough time and money to the effort. The larger the private key, the more difficult it is to determine, but a larger private key also takes longer to legitimately encrypt a signature within the fiscal printer. The goal is to use a private key small enough to be practically manageable, but large enough to be impractical to "hack".

As technology becomes better and cheaper over time (i.e., computer processors become faster and cheaper) , a key that is sufficient to provide adequate protection today, eventually becomes insufficient to maintain impracticality of hacking. The longer a particular key which is used is, the more likely that two things may happen; there are increasing numbers of samples of encrypted data to use as input to a hacking computer routine, and the key length itself becomes unmanageable.

SUMMARY OF THE INVENTION

Accordingly, the present invention provides a method to automatically and continuously reduce hacking susceptibility of data from an output device comprising the steps of: generating within said output device a private/public encryption key pair; calculating a viability time for said private/public encryption key pair; selectively publishing a public encryption key of said private/public encryption key pair while keeping a corresponding private encryption key stored in secured hardware in said output device; modifying said viability time based on inputted parametric data; and modifying said private/public encryption key pair based on comparison of a real time date to said viability time.

The present invention also provides a computer program comprising program code adapted to perform the method as described in the previous paragraph .

Preferably the output device's private key is small enough to allow for as fast a signature encryption as possible and secure enough to make it impractical to break the key, for the life of the device, without requiring manual intervention of every device installed.

According to a preferred embodiment a method and system are disclosed for optimizing the security of information generated by an output device. While private/public key encryption has been used, the present invention preferably discloses a method and system for applying this encryption technique to systems where employing latest technology may not be the most effective system.

Output devices have hardware that is tamper-evident and as such are accepted by certain governments as secure . Embodiments of the present invention extend this hardware with circuits and components that allow a private/public key pair to be generated once during manufacture and will cause erasure of the private key if the security of the hardware is broached without authorization. Embodiments of the present invention incorporate algorithms internal to the secure hardware that calculate the viability of a given length of private/public keys based on inputted parameters which include length the code has been in existence, technology advances and other factors with the intent of optimizing the length of time to encrypt as well as insuring a commensurate security level with the economic risk of unauthorized private key discovery.

The present invention further provides a system for automatically and continuously reducing hacking susceptibility of data from a output device comprising: an algorithm circuit for generating a private/public encryption key pair internal to secure hardware of said output device; a viability time circuit for calculating a viability time for said private/public key pair; a public circuit for sending a public key of said generated private/public key pair external to said output device; a first modifying circuit receiving inputted parametric data, said first modifying circuit operable for modifying said viability time using said inputted parametric data; and a second modifying circuit operable to change said generated private/public key pair based on a comparison of a real time date to said viability time.

The present invention further provides a data processing system, comprising: a central processing unit (CPU) ; shared random access memory (RAM) ; read only memory (ROM) ; an I/O adapter; an output device system as described in the previous paragraph; a display adapter; and a bus system coupling said CPU to said ROM, said RAM said display adapter, and the output device system described in the previous paragraph.

In one embodiment the output device is a fiscal printer.

BRIEF DESCRIPTION OF THE DRAWINGS

A preferred embodiment of the invention will now be described by way of example only and with reference to the following drawings: FIG. 1 illustrates a table having date, cost and time to break or hack a private key,-

FIG. 2 illustrates a flow diagram of method steps in an embodiment of the present invention;

FIG. 3 illustrates a system block diagram of an embodiment of the present invention; and

FIG. 4 is a system block diagram used in conjunction with embodiments of the present invention.

DETAILED DESCRIPTION

In the following description, numerous specific details are set forth such as specific word or byte lengths, etc. to provide a thorough understanding of the present invention. However, it will be obvious to those skilled in the art that the present invention may be practiced without such specific details. In other instances, well-known circuits have been shown in block diagram form in order not to obscure the present invention in unnecessary detail. For the most part, details concerning timing considerations and the like have been omitted in as much as such details are not necessary to obtain a complete understanding of the present invention and are within the skills of persons of ordinary skill in the relevant art.

Refer now to the drawings wherein depicted elements are not necessarily shown to scale and wherein like or similar elements are designated by the same reference numeral through the several views.

Throughout this disclosure private, public or private/public keys may be used synonymously to mean private, public, or private/public encryption keys. The word encryption may not be used in all cases for the sake of brevity.

Encryption involves the encoding and decoding of information by use of an algorithm. With private/public key encryption, there are two "keys". The public key is made available for use by anyone who wants to send a message to the owner of the private key. The sender uses the public key to encrypt the message which can then only be decrypted by use of the private key. The private key may also be used to encrypt a message which can be decrypted by anyone with access to the public key. The primary purpose of the private/public key encryption is to maintain message integrity in the sense that the message can be identified as having originated from the person with access to that private key, that is, authorship integrity. To some degree it also protects the security of the information in transit, although it may be read by anyone, in addition to the addressee, who has the sender's public key.

In embodiments of the present invention the public key is not public in the sense that it is broadcast to everyone, it is public in that it is given only to those with authorized access to a secured fiscal printer.

There is only one private key holder (e.g., the one in the fiscal printer) but there may be more than one public key holder in that the fiscal printer may communicate to more than one device. In one embodiment, the public key is placed in these devices as part of the installation process. A fiscal printer with private/public key encrypted devices may be commanded (via one of the established links at installation) to generate a new private/public key pair and send the new "public key" encrypted by the old private key. This new "public" key can be decrypted only by holders of the old public key. The fiscal printer now (e.g., by algorithm) destroys the old private key and sends a message encrypted with the new private key to holders of the new public key instructing these holders to destroy the old public key. A secure link is now established. Hardware 302 (see figure 3) has been accepted as secure by governments requiring fiscal printers if the hardware is tamper-evident (has features which indicate tampering) or has locking measures in place. The secure hardware in the fiscal printer has in one embodiment features that destroy the private key if it is tampered with and forces an intervention to reset the breached communication link.

In the above embodiment of the present invention a private/public key pair is generated at the time of installation. The public key is extracted and then the hardware is secured. Since the public key is in the hands of a "trusted" source and the private key is in the secured hardware secure communication can be transacted by the "trusted" source and the fiscal printer secured hardware. Since the private key, generated at this time, is available only to the hardware 302, secure communication can be established to the hardware 302 via the public key encryption (only the hardware can read the input) to input data (e.g., Input data 303) necessary for the hardware to execute security routines of the preferred embodiment. In one embodiment of the present invention, the secure hardware has read once inputs (the secure hardware accepts an external command from these inputs only once) that direct the hardware to generate a first private/public key pair at manufacturing time. The public key so generated is made available for additional communication such as reading in parameters pertinent to algorithms of the preferred embodiment as well as commanding the hardware to generate a new private/public key pair. The read once inputs allow a first time start or power up, provided the hardware 302 is secured. In one embodiment of the present invention, if the hardware security is broken, the generated private key is erased and internal circuitry would have to be replaced before a new power up and another read once could be commanded.

In FIG. 3, the report generating hardware 307 encrypts a signature for the entire tax reports with an installation generated private key

(process for generating private/public key described above) and sends the information to an external device 310 (one of the recipients of a public key at installation) which reads or authenticates the reports using the corresponding public key. To generate false reports one would have to "hack" the private key and generate encrypted reports that could be read by the existing public key. If the fiscal printer 306, which was part of a point of sales system, had cash register or credit card entry hardware which required the public key to complete transactions, then all transaction data would be guaranteed to be recorded by the secure hardware 302. Anyone making a transaction at a particular fiscal printer 306 would have had to enter the information on a device with previous public key authorization readable only by the particular fiscal printer (e.g., 306) with the corresponding private key. Also, journal printing station 309 likewise prints a record of all entered transactions with an encrypted signature (encrypted by a private key ensuring the source is known and verifiable by an authorized holder of the corresponding public key generated at installation) insuring it was the product of the fiscal printer 306 generating a particular private/public key pair.

A system, such as the one described in embodiments of the present invention, could preferably be defeated only by "hacking" the private key or by attempting to break into the secure hardware 302 of the fiscal printer 306 which in embodiments of the present invention destroy the private key and require a hardware installation too once again establish the integrity of the fiscal printer system. The preceding has detailed how a private/public key system may be used to ensure that the information from a fiscal printer, data or just a digital signature, may be verified as to its source (whether a particular fiscal printer is the source) . The present invention preferably provides for a way to allow a fiscal printer's logic in the secure hardware to automatically change its private/public key pair periodically. However, the fiscal printer microcode does not simply change its key pair at regular intervals. Rather it uses an algorithm that takes into account the changes in technology to always stay one step ahead of a hacker, while remaining as efficient as possible to legitimately encrypt a signature or data.

In one embodiment of the present invention this algorithm is written into the fiscal printer's microcode at manufacture time. The parameters for the algorithm are data from publicly available encryption industry estimates of time and money needed to break a key of a certain length (over the life of the printer) , along with estimates of how much tax money could be saved by creating false tax reports (e.g., signed with a hacked private key) for a particular fiscal printer (over the life of the printer) .

A hypothetical example of an industry estimate of the time required to break a key length of 128 bits might look like the chart in FIG. 1. Similar industry estimates may be determined for a 256-bit key, a 764-bit key, a 1024 bit key, etc. Obviously the larger the key size, the longer it takes and the more expensive it is to break the key.

The proposed algorithm takes this information for all key sizes, along with estimates of maximum taxes collected from any particular fiscal printer per year, and using the fiscal printer's built-in real-time clock 301, the algorithm estimates the life or viability time of the security of a particular private key at any point in time. In one embodiment the algorithm calculates the viable secure lifetime expectancy of a 128-bit private key put into service on a particular date. The algorithm in the secure hardware 302 continuously tests the 128-bit key's viability using updated information provided using a present public key. If the printer's microcode determines that the present key is not viable because of the length of time the present key has existed, in one embodiment it generates a new 128-bit key pair, which has a life expectancy that is again viable. However, the analysis may determine that generating a new 128-bit key is not viable and the secure hardware 302 automatically generates a new, longer, 256-bit key that is good for a viable period of time. This process continues, with new keys of the same length being generated, at ever decreasing intervals, until a new larger sized key is required. Data related to how may samples of encrypted data samples have been "presented" to the outside world may also be considered in the considerations of the viability of a public/private key pair. Sheer volume of the samples of data signed by encryption is one of the resources used by someone attempting to break the code. Embodiments of the present invention use the number of data samples that have been encrypted and sent external to the fiscal printer in the algorithm used to determine the public/private key viability.

Since key generation is a long involved process and since changing keys is potentially confusing to people trying to authenticate data on an ongoing basis, the algorithm preferably strikes a balance between increasing frequent changes of keys of the same length and simply changing to larger length keys, which initially require less frequent changes.

Although private keys are not revealed outside the secure fiscal printer logic, after creating a new key pair, the new public key is revealed outside the secure hardware 302. To ensure that the new public key indeed came from the secure fiscal printer, it is preferably part of a message that has a digital signature that was created using the printer's previous private key, ^"and can thus be authenticated as having come from the secure fiscal printer by using the previous public key.

FIG. 2 illustrates the method steps used in embodiments of the present invention. In step 201, a read once system start up is employed. This causes the secure hardware 302 to generate a first private/public key pair wherein the private key is retained inside the secure hardware 302 and the public key is delivered to selected users for use in further communications to the fiscal printer. In step 214, a check is done to see if the hardware is secure. If the hardware is not secure, then the private key is erased in step 213. In step 212, the read once circuits are re-installed, the hardware secured and a return is issued to step 201. If the hardware is secure in step 214, a check is done in step 215 to test if new data is available. If new data is available in step 215, then data on encryption economics is read in step 203. Fiscal printer tax data is read in step 204 and a branch is issued to step 210. In step 210, real time clock data is read and next in step 206 the private key birth data is compared to check point data and an action plan is determined using stored algorithms. The requirement for an action plan is checked in step 207. If an action plan is required, the required key length is determined, new keys are generated, new check point dates are set and a return is issued to step 214. If no action plan is required a branch is made to step 214.

Referring to FIG. 4, an example is shown of a data processing system 400 which is used for a preferred embodiment of the present invention. The system has a central processing unit (CPU) 410, which is coupled to various other components by system bus 412. Read- only memory ("ROM") 416 is coupled to the system bus 412 and includes a basic input/output system ("BIOS") that controls certain basic functions of the data processing system 400. Random access memory ("RAM") 414, I/O adapter 418, and communications adapter 434 are also coupled to the system bus 412. I/O adapter 418 may be a small computer system interface ("SCSI") adapter that communicates with a disk storage device 420 or tape storage device 440. Communications adapter 434 interconnects bus 412 with an outside network enabling the data processing system to communicate with other such systems. Input/Output devices are also connected to system bus 412 via user interface adapter 422 and display adapter 436. Keyboard 424, track ball 432, mouse 426 and speaker 428 are all interconnected to bus 412 via user interface adapter 422. Display monitor 438 is connected to system bus 412 by display adapter (controller) 436. In this manner, a user is capable of inputting to the system through the keyboard 424, trackball 432 or mouse 426 and receiving output from the system via speaker 428 and display 438.

In a retail operation environment the data processing system of FIG.

4 may include additional devices such as a fiscal printer system 441 containing a secure hardware 302 for receiving or generating private/public encryption keys. The fiscal printer system 441 preferably receives and outputs data via user interface adapter 422.

Fiscal printer system 441 preferably also includes circuits for erasing a generated private key if the secure hardware 302 is broached in an unauthorized manner. Fiscal printer system 441 also includes circuits that enable a read once command to generated, internal to the secure hardware 302, a private/public key pair and also require the read once circuits to be replaced if the secure hardware 302 is breached in an unauthorized manner.

Whilst the invention has been described in terms of data from a fiscal printer, it is in no way intended to be limited to such. The term should be taken as encompassing any output device which is outputting encrypted data.

Claims

1. A method to automatically and continuously reduce hacking susceptibility of data from an output device comprising the steps of:

generating within said output device a private/public encryption key pair;

calculating a viability time for said private/public encryption key pair;

selectively publishing a public encryption key of said private/public encryption key pair while keeping a corresponding private encryption key stored in secured hardware in said output device;

modifying said viability time based on inputted parametric data; and

modifying said private/public encryption key pair based on comparison of a real time date to said viability time.

2. The method of claim 1, wherein said viability time is an estimated time required for the unauthorized discovery of said private encryption key

3. The method of claim 1 wherein said viability time is set to an optimal value compared to an encryption time resulting from using said private encryption key.

4. The method of claim 1, 2 or 3 , wherein said inputted data includes data on technology advances in unauthorized discovery of encryption keys.

5. The method of claim 1, 2, 3 or 4, wherein said viability time is maintained by generating a new private/public encryption key of increased length.

6. The method of claim 1, 2, 3 or 4, wherein said viability time is maintained by generating a new private/public encryption key of a previous length.

7. The method of any preceding claim, wherein said publishing of said public encryption key comprises the step of printing said public encryption key on a receipt for later use in digital signature authentication .

8. The method of any preceding claim, wherein said secured hardware is locked against outside discovery of said private encryption key.

9. The method of any preceding claim, comprising the step of erasing said private encryption key in said secured hardware if said secured hardware is breached.

10. The method of any preceding claim, wherein said comparison of said real time date and said viability times is repeated at determined intervals .

11. The method of any preceding claim, wherein said viability times are updated by secure communication of data to said output device.

12. A system for automatically and continuously reducing hacking susceptibility of data from a output device comprising:

an algorithm circuit for generating a private/public encryption key pair internal to secure hardware of said output device;

a viability time circuit for calculating a viability time for said private/public key pair;

a public circuit for sending a public key of said generated private/public key pair external to said output device;

a first modifying circuit receiving inputted parametric data, said first modifying circuit operable for modifying said viability time using said inputted parametric data; and

a second modifying circuit operable to change said generated private/public key pair based on a comparison of a real time date to said viability time.

13. The system of claim 12, wherein said viability time is an estimated time required for the unauthorized discovery of said private encryption key

14. The system of claim 12, wherein said viability time is set to an optimal value compared to an encryption time resulting from using said private encryption key.

15. The system of claim 12, 13 or 14, wherein said inputted data includes data on technology advances in unauthorized discovery of encryption keys .

16. The system of claim 12, 13, 14 or 15, wherein said viability time is maintained by generating a new private/public encryption key of increased length.

17. The system of claim 12, 13, 14 or 15, wherein said viability time is maintained by generating a new private/public encryption key of a previous length.

18. The system of any of claims 12 to 17, wherein said publishing of said public encryption key comprises means for printing said public encryption key on a receipt for later use in digital signature authentication.

19. The system of any of claims 12 to 18, wherein said secured hardware is locked against outside discovery of said private encryption key.

20. The system of any of claims 12 to 19, comprising means for erasing said private encryption key in said secured hardware if said secured hardware is breached.

21. The system of any of claims 12 to 20, wherein said comparison of said real time date and said viability time is repeated at determined intervals .

22. The system of any of claims 12 to 21, wherein said viability times are updated by secure communication of data to said output device.

23. A data processing system, comprising:

a central processing unit (CPU) ;

shared random access memory (RAM) ;

read only memory (ROM) ; an I/O adapter;

an output device system as claimed in any of claims 12 to 22 or claim 26;

a display adapter; and

a bus system coupling said CPU to said ROM, said RAM said display adapter, and said output device system.

24. A computer program comprising program code adapted to perform the method of any of claims 1 to 11.

25. The method of any of claims 1 to 11, wherein the output device is a fiscal printer.

26. The system of any of claims 12 to 22, wherein the output device is a fiscal printer.