Patent Application
20060020788
The present invention relates to a self-service terminal, such as an automated teller machine (ATM).
Self-service terminals are increasingly making use of peripheral devices, for example dispensers, card readers, printers etc, that are connected by open, standardized communication links such as USB and RS232. The nature of such communication links is that they are insecure, opening the door to various attacks on system security such as passive attacks, e.g., eavesdropping to obtain private information, and active attacks, e.g., sending a command to a cash dispenser to dispense money without authorization. Historically, the industry has avoided this problem by using proprietary communication links or unpublished message formats. However, these increase cost and decrease interoperability.
According to one aspect of the present invention, there is provided a self-service terminal comprising a core; one or more peripheral devices operable to communicate with the core, and means for encrypting signals for sending between the core and the one or more peripheral devices. Preferably, the means for encrypting are operable to use key based encryption.
By encrypting messages for sending between the core and the peripheral devices, security can be improved. This makes the terminal less susceptible to fraud.
The key based encryption may be symmetric key encryption. This may be used for transmitting messages between the core and the peripheral device.
The key based encryption may be asymmetric key encryption. This may be used for key management purposes.
The peripheral device may be operable to generate a session key and use that key to encrypt messages for sending to the core. The peripheral device may be operable to generate the session key using a random or pseudo-random key generation process. Preferably, the peripheral device is operable to encrypt the session key and send the encrypted key to the core. The peripheral device may be operable to encrypt the session key using a public key of a public/private key pair. In this case, the core includes or has access to the private key of the public/private key pair and is operable to use the private key to decrypt the session key, and store that session key for decrypting subsequent messages from the peripheral device.
The peripheral device may be operable to generate an initial session key in response to detection or sensing of a predetermined act or event. The pre-determined act may be a pre-determined physical or mechanical act. Where the peripheral device is a cash dispenser, the pre-determined act may be opening of a safe door or activation/de-activation of a lock mechanism associated with the safe. In either case, a sensor may be provided for directly or indirectly sensing the pre-determined act.
The peripheral device may be operable to change the session key. The peripheral device may be operable to encrypt the new session key using the current session key and additionally a public key of a public/private key pair. The peripheral device may be operable to change the session key after expiry of a pre-determined time. The peripheral device may include a timer for determining when the pre-determined time has elapsed.
The peripheral device may be operable to include in each message a number that is incremented/decremented each time a new message is sent, and encrypt at least the part of the message that includes the number. In practice, this means that each new message should have a number that is uniquely associated with it. The core may be operable to monitor the numbers in each message received. The core may be operable to keep a record of the numbers already received, and compare the numbers of newly received messages with those stored numbers. In the event that the newly received number is the same as one of the previously received numbers, the core is adapted to recognize that this is either an error or an attempted fraud. Alternatively or additionally, the core may merely compare the number of the newly received message with an expected number. Again in the event that there is a discrepancy, this would be indicative of an error or fraud.
Preferably a plurality of peripheral devices is provided. Each peripheral device includes means for generating a session key, which key can be uniquely identified with it.
According to another aspect of the present invention, there is provided a method for initializing a secure communication process in a self-service terminal comprising a core, and one or more peripheral devices operable to send messages to the core, the method comprising sensing a pre-determined act or event at the peripheral device; in response to sensing of the pre-determined act or event, generating within the peripheral device a session key; encrypting that session key; sending the encrypted session key to the core, decrypting the session key and storing the session key in a secure area.
The session key may be encrypted using an asymmetric encryption process. The session key may be encrypted in the peripheral device using a public key of a public/private key pair. The session key may be decrypted in the core using the private key of the public/private key pair.
According to yet another aspect of the present invention, there is provided a peripheral device for use in a self-service terminal comprising a central control unit or core, the device comprising means for sensing a pre-determined act or event at the peripheral device; means for generating a session key in response to sensing of the pre-determined act or event; means for encrypting that session key, and means for sending the encrypted session key to the core.
Various aspects of the invention will now be described by way of example only and with reference to the accompanying drawings, of which:
Any suitable encryption technique can be used for encrypting messages for sending between the control unit 10 and the peripheral device 14 via the communication link 16. In the terminal of
In order to implement the encryption/decryption, encryption keys are stored in the secure areas 24, 26 of both the core 10 and the peripheral device 14. For asymmetric encryption, each has to share a common public/private key pair. For symmetric encryption, each has to have access to the same session key. To this end, the central unit 14 includes a private key, preferably a RSA private key, a public key, again preferably a RSA public key, and a triple-DES session key. The peripheral device includes a public key, again preferably a RSA public key, and a 3DES session key. The real-time software 20 and the control software in the core 10 have built in knowledge of the relevant public key encryption system.
Each of the public and private keys is generated externally of the terminal 8. The public key is stored in the persistent memory 24 of the core 10 and peripheral devices 14. The private key is stored in only the core 10. Storing the public and private keys is done when then terminal is being built and/or developed. As will be appreciated, if this key pair is updated, for example, if the initial pair is compromised, then both the PC device software 12 and the RT-device software 18 need to be redeployed at the same time. This may require a firmware update on the device. In contrast, the session key is generated by the peripheral device 14. After generation, the session key is stored in the internal memory of the device and then encrypted using the public key and sent to the core 10
For security reasons prior to installation neither the core 10 nor the peripheral device 14 includes a copy of the session key. Instead, this is generated in the peripheral device 14 as part of an initialization process. In order to initialize the peripheral device 14 of
In the event that the dispenser 14 is opened, and the safe is accessed, this is recognized by the dispenser as authorization to generate an initial session key. The dispenser firmware then generates a random session key and stores it in the private, non-volatile location of memory 26. The session key is then encrypted with the firmware's public key and sent to the PC device software 12 via the USB driver 16. Once received, the software 12 is able to decrypt the message using the private key and so reveal the newly generated session key. The PC device software 12 must securely hide the private key to prevent the session key being decrypted by an attacker. The PC device software 12 then stores the session key in a private, non-volatile area, so that both the core 10 and the peripheral device 14 share the same, common session key.
Once the session key is generated and the core 10 and peripheral device 14 initialized, messages sent between them can be encrypted using the session key.
This encryption facility provides confidentiality for messages being sent to and from the core 10 and the peripheral device 14. To improve security further and provide authentication, a simple incrementing command sequence number can be included inside the encrypted message. This is useful because while encryption provides some protection against all passive attacks and some active attacks, there is a particular active attack known as message replay that encryption alone cannot prevent. Message replay involves recording a message with a known effect on its way to or from a device, with the intention of later replaying the message to simulate a valid device communication. For example, if a command to dispense cash is recorded it might be replayed (sent to the dispenser) in an attempt to dispense more cash without authorization. This is not prevented by encryption since the attacker does not need to inspect or understand the contents of the data packet. By including an incrementing sequence number in the encrypted portion of messages, there is provided a mechanism for ensuring that a replayed message is not accepted as authentic. Because the incrementing sequence number is inside the encrypted portion of the message it cannot be altered or inspected, but can be verified by the receiving node to ensure that the message is not a repeat of an earlier message.
To deal with the inclusion of the simple incrementing command sequence, the core 10 is operable to monitor the numbers in each message received. This can be done in various different ways. For example, the core 10 may keep a record of the numbers already received, and compare the numbers of newly received messages with those stored numbers. In the event that the newly received number is the same as one of the previously received numbers, the core 10 is adapted to recognize that this is either an error or an attempted fraud. Alternatively or additionally, the core 10 may merely compare the number of the newly received message with an expected number. Again in the event that there is a discrepancy, this would be indicative of an error or fraud.
Further security may be provided by having periodic changes of session key.
Using a session key as part of the encryption process provides protection against what is sometimes referred to as a “rogue host” attack. In this type of attack, a peripheral device, such as the cash dispenser, is unplugged from the core USB 16 and plugged into a notebook PC instead. The notebook PC can have the appropriate device driver software available such that when the device is connected, an application-programming interface is installed by the plug-and-play driver installation. However, this rogue host cannot be allowed to drive the device without authorization. In particular, the rogue PC cannot control the device without the session key. Furthermore, the host PC cannot initiate the generation of a new session key for device communications. This can only be done by the peripheral device 14 itself, and only when a trusted party has verified that the device is correctly connected to the control unit in the terminal. The trusted party must also prove that they are authorized to generate a new session key by accessing a secure trigger mechanism, for example, proving access to the safe. Any periodic expiration of a session key must be negotiated for using the new session key encrypted with the old session key. This means that a rogue host cannot wait for key expiration to establish communications with a device.
The terminal in which the invention is embodied prevents unauthorized access to security-critical system devices, in an open standard interface to drive the device (e.g., CEN XFS). Hence, a proprietary API is not needed. The terminal can also be used in an open, extendible PC host system, with no restrictions on level of change that can be applied to the PC system software. For example, new applications can be added by authorized means without preventing device access. The invention also allows the use of industry standard, strong encryption methods to prevent an attacker infiltrating the system. In practice, this means that a casual attack will not succeed. In addition, since the terminal in which the invention is embodied is independent of any particular PC peripheral device interconnection technology, it is well suited to standard connection methods such as RS232 or USB.
A skilled person will appreciate that variations of the disclosed arrangements are possible without departing from the invention. For example, not all messages passed between a peripheral device and its associated control unit need be encrypted. The choice of which messages to encrypt is the decision of the device software-knowledge that is shared by both the RT-software and the device personality. Generally, a device would not necessarily need to encrypt messages that do not present a security risk, for example retrieving an operational status value from the device. Accordingly the above description of the specific embodiment is made by way of example only and not for the purposes of limitation. It will be clear to the skilled person that minor modifications may be made without significant changes to the operation described.
| Number | Date | Country | Kind |
|---|---|---|---|
| 0414840.9 | Jul 2004 | GB | national |
