1
Integrity Protection for Automated Teller Machines Ronald Petrlic University of Paderborn 33100 Paderborn
[email protected]
Abstract—In this paper we propose an integrity protection concept based on Trusted Computing. The Trusted Platform Module (TPM) is used to measure the integrity of the ATM. We show that the measurement results can be reported authentically to the bank and the ATM manufacturer. We also discuss how an integrity evaluation based on the report can be performed — allowing the bank to put an ATM out of operation as an integrity violation is detected. Our solution provides protection against offline attacks performed by insiders. Index Terms—Automated Teller Machine (ATM) Security; Integrity Protection; Trusted Computing
I. I NTRODUCTION In 2009, a spectacular case of ATM defraud took place in Russia and Ukraine. [1] The particular of this case was the course of action taken by the defrauders to attack ATMs at large scale. The defrauders did not employ a hardware integrity violation against the ATMs — as it is the case with skimming attacks — but they employed a software integrity violation instead. This is the first case that was published in which malware was set up on ATMs to grab user data — there are some known software manipulations of ATMs targeted at stealing money though [2], [3]. The main question was who could carry out such a sophisticated so-called offline attack where direct access to the system computer that works within the ATM is needed. It is assumed that the attack was carried out by an insider who worked at the bank and who had legitimate access to the ATM. In 2010, the researcher Barnaby Jack caused a media coverage when he “jackpotted” ATMs at the Black Hat Technical Security Conference. [4] Nowadays’ ATMs are protected against network attacks as well as against attacks from insiders that have access to ATMs — while in operation — for maintenance work, e.g. to install up-to-date security patches. We classify those kinds of attacks as online attacks. More precisely, we define an online attack as an attack that takes place after the operating system has been started. An offline attack, on the other hand, is performed in a state in which the system is not running, or prior to the start of the operating system, i.e. during bootup. All the attacker needs is (physical) access to the system computer. Thus, we are limiting the circle of attackers that come into consideration to insiders. Insiders are in a position to target an ATM’s integrity and thereby, to circumvent all software protection mechanisms in place. Imagine that a local bank administrator inserts a boot CD or an USB device
containing a live operating system after switching on the ATM and booting that system. Then the attacker manipulates the files of the protective system. After a reboot to the genuine system, all protective mechanisms are out of place and the attacker is free to go. The Russian case, as discussed above, shows that the presumption that an insider might turn bad and manipulate an ATM is not so far-fetched. Another problem is that all the applications running on an ATM are executed within one single operating system. A malicious application setup by an insider may compromise the whole system and thus allowing the attacker to gain almost full control over the ATM. Operating systems indeed provide isolation between applications. However, state of the art operating systems are very complex and the (integrated) protective mechanisms in place are regularly by-passed by exploitation of security holes. The main contributions that we make in this paper are: ∙ Our proposed concept protects ATMs from being manipulated by inside attackers. ∙ Banks are aware of their ATMs’ system states at all times. ∙ ATMs may be customized by banks with new applications, e.g. ticketing applications — it is assured that those applications cannot harm any critical ATM applications. The remainder of this paper is structured as follows. We cover the building blocks of our proposed concept in Sect. II. In Sect. III we point out the requirements for an integrity protection concept for Automated Teller Machines and in Sect. IV we present a concept that takes those requirements into account. The concept is evaluated in Sect. V. Related work is covered in Sect. VI. In Sect. VII we draw a conclusion and give an outlook. II. B UILDING B LOCKS A. Trusted Computing We do not give an in-depth introduction into Trusted Computing here, but we rather focus on the key functionalities our concept is based on. Trusted Computing, as defined by the Trusted Computing Group (TCG), “is the expectation that a device will behave in a particular manner for a specific purpose” [5]. For this purpose, the following components and functions are employed. 1) Trusted Platform Module: The Trusted Platform Module (TPM), a secure coprocessor realized as a micro-controller, is the central component that allows for building trust in a
2
system that employs such a hardware module. The chip is physically bound to a certain platform and basically provides some storage as well as some cryptographic functions. Each TPM is shipped with a unique so-called endorsement key (EK). The 2048 bit private RSA key, which cannot leave the TPM, can be used by another party to identify a TPM and thus, a certain platform, uniquely. For remote attestation, as discussed below, an attestation identity key (AIK) is used. This key is certified by a trusted third party (TTP), or Privacy CA in the Trusted Computing context — guaranteeing that the AIK belongs to a certain platform. Storage is provided within the TPM by Platform Configuration Registers (PCRs). Those registers allow for a storage of 160 bit hash values each, and the particularity is the way they are set, which is as follows: 𝑃 𝐶𝑅𝑖 = 𝑆𝐻𝐴−1(𝑜𝑙𝑑 𝑃 𝐶𝑅𝑖 𝑣𝑎𝑙𝑢𝑒 ∣∣ 𝑛𝑒𝑤 𝑣𝑎𝑙𝑢𝑒 𝑡𝑜 𝑏𝑒 𝑠𝑒𝑡), where the 𝑖𝑡ℎ register value is set to the hash value of the concatenation of the old register value and the new value that should be set. Thus, a simple overwriting of an old hash value by a new one is not possible — which means that an attacker cannot directly manipulate those registers. When we are talking about integrity measurement in the remainder of this paper, we mean that the SHA-1 cryptographic hash value of some file is computed and stored within a PCR. Integrity evaluation, on the other hand, is the check of the integrity of the system based on the PCR values that represent the system state against a set of known hash values that represent trusted and untrusted system states. 2) Trusted Boot and IMA: In the literature, the terms Secure Boot, Authenticated Boot, and Trusted Boot are often used synonymously — however, there is a differentiation. Secure boot can be seen as an active security mechanism that stops the boot process as soon as an integrity violation is noticed. Thus, a system that boots up properly is known to be in an uncompromised state. On the other hand, an authenticated boot can be seen as a passive security mechanism in which the boot process is measured and logged within PCRs. This mechanism does not prevent a system from booting into an insecure system state but the integrity violation can be noticed after boot-up. Trusted boot constitutes a combination of both approaches. Authenticated boot constitutes a major functionality of Trusted Computing. This process is shown in Fig. 11 .
computing platforms. The CRTM code is executed first of all when the computer is started, and its task is the measurement of the (modifiable) BIOS code (step 1 in the figure). After that, the BIOS is executed (step 2). The BIOS measures the boot loader and passes control over to the boot loader (steps 3 and 4). Those steps are specified by the TCG. Next, a modified boot loader, e.g. TrustedGRUB [6], measures parts of the operating system and executes it (steps 5 and 6). TrustedGRUB extends the authenticated boot process as specified by the TCG and it also contains a secure boot component meaning that the boot process is stopped by TrustedGRUB if some files, as specified during the initialization, are compromised. To further extend the chain of trust up to the application level, S AILER [7] proposed an Integrity Measurement Architecture (IMA) for Linux. IMA is placed within the operating system kernel to be able to intercept any executables, kernel modules, and configuration files that are loaded and to measure them before they are actually executed. The measurements are stored within a list and an aggregate over all the measurements is stored within a PCR. Thus, IMA provides a run-time integrity measurement functionality for Linux. 3) Remote Attestation: Remote attestation denotes the process of proving that the platform is authentic and the system is in a certain state to another party. The verifier, which is the remote party that wants to check the system’s integrity, requests the system to attest its system state and therefore challenges the system with a nonce to prevent replay attacks. The system signs the requested PCR value with its private attestation identity key within the TPM and provides the remote party with the PCR value, the signature, and its AIK certificate that contains the corresponding AIK public key. The remote party is able to check the signature as it trusts the Privacy CA issuing the AIK certificate. Furthermore, it can evaluate the integrity of the system by checking the PCR value — that represents the system state — against a database of known trusted and untrusted states. 4) Sealing: Key wrapping means that a key is encrypted with a wrapping key and stored externally. Sealing is an extension of key wrapping. The particularity of sealing is that the wrapping key may only reside within the TPM and it is further bound to a certain system state. Thus, the release of the key, i.e. its decryption with the wrapping key, is only possible on the same platform and within the same system state as the system was when the key was sealed. B. Virtualization
Fig. 1.
Authenticated boot
The Core Root of Trust for Measurement (CRTM) is typically a non-modifiable extension of the BIOS on nowadays’ 1 Note
that the process is demonstrated in a simplified manner in the figure.
1) Virtualization Technology: Virtualization allows different operating systems to be running on the same physical machine at the same time. Isolation between the systems is featured with the support of the CPU. A so-called Virtual Machine Monitor (VMM), or Hypervisor, is put between the hardware and the (simultaneously running) operating systems. It is the VMM’s task to abstract from hardware resources that it has full control over — i.e., it manages I/O and provides CPU time and memory to each (isolated) virtual machine (VM) that runs an operating system. The VMM needs full access to the CPU and thus, is executed in a privileged mode. Xen is
3
vTPM-Manager
VM0
(Dom0)
Server-Side TPM Driver
Application n
Application 1
Application n
Application 1
vTPM Instance 1
vTPM Instance n
a popular VMM under the GNU GPL. In Xen terminology, virtual machines are called domains. The first domain, Dom0, is the one that is started during the boot of the VMM. This domain is the only one that is privileged and thus, it is used to control the other domains, called DomU. 2) Virtual TPM: Enabling virtual machines access to a TPM requires a virtualization of the (hardware) TPM. B ERGER ET AL . [8] present such a virtualization approach for Xen and call their virtual TPM vTPM. The architecture is shown in Fig. 2.
Operating System
Operating System
VM1 (DomU)
VMn (DomU)
Client-Side TPM Driver
Client-Side TPM Driver
Hypervisor TPM
Fig. 2.
Hardware
Concept of a virtualized TPM (vTPM)
Only Dom0 gets direct access to the hardware TPM and provides the other virtual machines, or domains, with their own vTPM instances by making use of the vTPM-Manager that runs in Dom0. Each vTPM is assigned its individual EK as well. III. R EQUIREMENTS Our goal is to protect an ATM from insiders performing offline attacks against the system’s integrity. An offline attack is an attack that is performed in a state in which the system is not running or during boot-up. We assume that the attacker has complete knowledge about the employed security mechanisms, enough resources, especially time and money, to carry out an attack, and full access to the system. Such an attacker could be, for example, a local bank administrator.2 The requirements for our integrity protection concept are as follows: 1) An ATM must not start if its integrity has been compromised. 2) An ATM can be checked periodically by the manufacturer and the bank — whether the running system is still uncompromised. 3) Applications provided by the bank must be isolated from applications provided by the ATM manufacturer — not only by means of the operating system. 4) Applications provided by the bank must not get access to ATM hardware devices (Encrypting PIN Pad (EPP), card reader, and cash withdrawal component). Regarding the first requirement, we do not only consider integrity violations due to file modifications but also replacements of any hardware devices within the ATM’s system computer. We do not take externally attached skimming devices into account — hardware integrity protection of an ATM is assumed to be solved by other mechanisms. The first requirement 2 Note that we assume in this paper that the ATM manufacturer’s security personnel are trustworthy.
means that if any component in the chain up to the operating system has been tampered with, the boot-up must not succeed. With the second requirement, we ask for an accommodation of our concept to protect an ATM’s integrity at the application level as well. If any malicious application is executed, the ATM should be put out of operation. To check the integrity of the running system, information about which applications have been executed so far is needed. The software versions of the applications also play a major role, e.g. whether the latest updates are employed. The ATM has to communicate its up-to-date system state periodically towards the manufacturer and the bank to allow them to initiate a (remote) shutdown of the ATM in case of an integrity violation. Note that this requirement targets online attacks as well. However, we do not take exploitations of security holes present in legitimate software into account at this point. We are in line with a major VISA requirement. As a result of the Russian case, as covered in the introduction, VISA published a “VISA Europe Data Security Alert” about the “Compromise of ATM PIN Transactions” [9]. Their Risk Mitigation Strategy requires the implementation of software integrity and authenticity testing upon start-up and at least once per day to help determine whether the ATM is in a compromised state. Even if malicious bank administrators constitute an attack potential, we must not prevent a bank from setting up software on an ATM. It is a major requirement on the part of banks to be able to customize ATMs by setting up their own applications. Banks are asking for an “ordinary” operating system, like Windows XP, to reduce the expenditure for their employees to install software or present advertisement on the screen. With our third requirement we want to avoid that malicious programs — setup by a local bank administrator — can interfere with applications provided by the ATM manufacturer. Moreover, applications provided by the bank must not get access to the “critical” ATM hardware devices at all. Thus, any malicious bank application is limited in its harm potential. In the next section, we come up with a concept that takes our requirements into account. IV. I NTEGRITY P ROTECTION C ONCEPT The concept we present in this section is based on a secure virtual environment. We come up with our proposed architecture in Sect. IV-A. The tasks integrity measurement and integrity evaluation are covered in Sect. IV-B and Sect. IV-C. As we have discussed in the last section, banks require to be able to install software on their ATMs without high expenditure. In Sect. I, we have also pointed out that it is problematic that applications from the ATM manufacturer are executed within the same system as bank applications. A. Proposed Architecture The overall ATM architecture we propose is shown in Fig. 3. As shown in the figure, there is no single operating system any longer, but we have rather split up this system — according to its tasks — into three systems: the basic system, the manufacturer system, and the bank system.
4
Basic System (Dom0)
Manufacturer System (DomU)
access to
Bank System (DomU)
access to
vTPM
vTPM VMM
TPM
CRTM
Hardware
Card Reader, EPP, and Withdrawal Device
Fig. 3. Proposed ATM system architecture. The components that make up the TCB are highlighted in bold.
The Trusted Computing Base (TCB), which is crucial for the whole system’s security, is constituted by the VMM, the basic system that sits on top of it, the TPM and CRTM, as well as the card reader, the Encrypting PIN Pad (EPP), and the cash withdrawal device. 1) Basic System: The basic system is the privileged system, Dom0, that has direct access to the TPM. This system is not only responsible for providing the other virtual machines with virtual TPM instances (vTPMs), but it is also the basic system’s task to perform remote attestation towards the manufacturer server and decrypt and start the manufacturer system as well as the bank system if the ATM is not compromised. We assume that the basic system is a very specialized system with some exactly specified tasks. It does not need to provide too much functionality and updating the system is negligible and thus, we can omit the challenges that regular updates would involve. The system is encrypted by the ATM manufacturer and the key is sealed to the state of the ATM as it is delivered — the ATM hardware components are part of the sealing properties as well. The key for the decryption, which is performed by the VMM, is only released by the TPM if the ATM is in the same state as during the deployment. 2) Manufacturer System: The manufacturer system is a closed system that comprises the applications that provide the basic functionality of an ATM, e.g. the cash withdrawal application constitutes such a task. The basic idea of the introduction of this system is the separation from the bank system the bank administrators have access to. This system is the only one that gets access to the EPP, the card reader, and the cash withdrawal device. We propose to encrypt and authenticate all communication between the manufacturer system and those ATM hardware devices — the proper (sealed) keys to be released to this system only. Thus, we can prevent malicious software installed by bank administrators within the bank system from gaining access to the ATM hardware components. The manufacturer system is encrypted by the ATM manufacturer. The key for the decryption is released to the basic system by the manufacturer server after the remote attestation is being performed, as covered in Sect. IV-C. 3) Bank System: The bank system is the one that bank administrators have access to and where they are allowed to install applications to extend the ATM’s functionality. As we have pointed out, applications within this system do not get access to any ATM hardware components — except for the touch screen to allow for basic user input — and thus, if a malicious application is installed by a bank administrator, the attack possibilities are limited. Within this system, an online protection suite is installed to prevent illegitimate access. The
bank system is encrypted by the bank that operates the ATM. The decryption key is needed by the basic system and it is released by the bank server as discussed in Sect. IV-C. As an example for an application provided by the bank we may look at a ticketing application that allows customers to buy tickets for events at an ATM. Such an application may request user data by an authentication and legitimation provider running within the manufacturer system. It is the provider’s task to authenticate a user, via bank card and PIN, and legitimize the purchase of the ticket towards the ticket application by asking for the user’s legitimation PIN. The provider, on the other hand, only handles requests that come from a trusted bank software, i.e. the ticket application needs to be signed by a trusted third party for the provider to release authentication information and authorize a ticket sale. 4) Manufacturer and Bank Server: We introduce a manufacturer server and a bank server that closely work together. Those servers will be used by the ATMs to periodically attest their system state to — allowing the manufacturer to check the current integrity of an ATM and allowing the bank to put a compromised ATM out of operation remotely. B. Integrity Measurement The integrity measurement is a task that takes place at different levels. First of all, the boot process up to the start of the VMM has to be measured. For that purpose, we employ the authenticated boot mechanism provided by the TCG, as discussed in Sect. II-A. Moreover, we employ TrustedGRUB to measure the VMM as well. The VMM proceeds with measuring the basic system. Within the basic system, we employ the Integrity Measurement Architecture (IMA), as discussed in Sect. II-A, to take measurements of all programs that are executed. As the manufacturer system is started, basically the same measurement procedure — made up by authenticated boot and IMA — is performed within that system. The main difference for that system is that the hardware TPM PCRs cannot be employed to store the hash values but the vTPM PCRs have to be used instead. When it comes to the start of the bank system, the measurements are performed again. As part of this procedure, the files of the security suite that is executed within the bank system are also measured. However, within the bank system — which will be a Windows system again — the employment of IMA is not possible as it is not available for Windows systems. During the ATM’s operation, we need proof that the security suite within the bank system is still running and that it is upto-date. We propose that the security suite actively gives some kind of a “sign of life” from time to time. We may assume that this application is the only one that is given access to the vTPM within the bank system — i.e. the authorization code for the vTPM is only known by that application. It is the application’s task to periodically log an entry of the form 𝑐𝑢𝑟𝑟𝑒𝑛𝑡 𝑡𝑖𝑚𝑒𝑠𝑡𝑎𝑚𝑝 ∣∣ 𝑠𝑜𝑓 𝑡𝑤𝑎𝑟𝑒 𝑣𝑒𝑟𝑠𝑖𝑜𝑛 and compose a hash aggregate in a PCR. The current timestamp is needed to prevent replay attacks and the information about the software version is needed as the security suite needs to be up-to-date at any time.
5
Next, we investigate how all those integrity measurements that we have collected can be evaluated and how to treat them. C. Integrity Evaluation The integrity evaluation, based on the measurements performed as discussed above, takes place at different levels. The first evaluation is performed during the execution of TrustedGRUB. If any file changes of the VMM at this stage are noticed, the boot process is stopped immediately3 . As the basic system is encrypted, we have to decrypt the system before it can be started, within the VMM. Therefore, the VMM needs to request the release of the proper key by the TPM. As we have mentioned earlier, this key is sealed to certain PCR values — this is how we prevent the release of the key in a “wrong” context, e.g. the hard drive of the ATM has been removed and the system should be decrypted on another machine, or any of the ATM hardware devices has been replaced. Note one detail about the protection of the secure boot component at this stage. It is important to incorporate PCR-13 for the sealing of the key as this PCR value contains a hash value of the files that are checked of the VMM, according to the TrustedGRUB specification [6]. Otherwise the secure boot component could be circumvented by an attacker who changes a file of the VMM and modifies the reference value as well. In a next step, the evaluation of the integrity of the basic system and the applications running within that system is performed. Therefore, we have to perform remote attestation towards the manufacturer server. As the integrity evaluation up to this point has been performed locally — and the manufacturer server can rely on this fact, based on the TPM as the trust anchor — we just have to attest the list that is maintained by IMA and PCR-20, which protects the list from tampering with [7]. With this approach, we have extended the chain of trust from the CRTM up to application level within the basic system. It is the server’s task to go through the list and check the hash values of the executed software against a black- and whitelist. If all programs that have been executed within the basic system are classified as “good” and the comparison of the computed hash aggregate of those hash values against PCR20 matches, the manufacturer server can list the ATM as being uncompromised. After the first remote attestation after the start-up of the ATM, the manufacturer server provides the ATM with the key to decrypt the manufacturer system. Therefore, the server encrypts this key with a public key of the ATM whose corresponding private key is stored within the TPM of the ATM’s system computer. Thus, only the TPM may decrypt the key for the decryption of the manufacturer system. The server may put the ATM out of operation remotely in case it detects an integrity violation and will at the same time list the ATM as compromised in its database. The integrity evaluation during the start-up of the manufacturer system is basically the same as the one during the start-up of the basic system. The system requires the TPM to release the keys for the communication with the ATM hardware devices and remote attestation is performed towards the basic system. Thus, it is the basic system’s task to (periodically) evaluate the 3 Note
that this is provided by the secure boot component of TrustedGRUB
integrity of the manufacturer system. In case of a manipulation detection, the basic system informs the manufacturer server about the incident. For the bank system being able to get started, the basic system needs to get the proper decryption key from the bank server first. The bank server — assured by the manufacturer server that the ATM is uncompromised — provides the TPM with the encrypted key. During the startup of the bank system, TrustedGRUB, running within the bank system virtual machine, evaluates whether the security suite has been manipulated and stops the start-up in case of a compromise. Note that by checking the integrity of the security suite at this stage, we can later on rely on the integrity of the bank system as we can trust that the signs of life have been created correctly. Those concatenations of the current timestamp and the security suite version number have to be checked by the bank server. Therefore, the basic system periodically provides the bank server with the measurement log and the corresponding signed PCR value. V. E VALUATION OF OUR C ONCEPT We required that an ATM must not start if its integrity has been compromised (1). The key to decrypt the basic system is not released by the TPM if the chain of trust cannot be established, i.e. if there is an integrity violation. Thus, the first requirement is met. In addition, we required that an ATM can be checked periodically by the manufacturer and the bank — whether the running system is still uncompromised (2). The permanent integrity measurement carried out by the integrity measurement architecture and the corresponding remote attestation towards the ATM manufacturer and the bank, allows for the bank to know about the ATM’s current state all the time. The bank is able to put the machine out of operation in case of an integrity violation. We cannot prevent the exploitation of security holes. Even if the systems are isolated from each other, a security hole within the VMM could have major impact on all the systems running on top of it. However, the report about the system and software configuration also contains information about the current patch-level of the system. Thus, an ATM that executes software that is known to contain security holes can be updated immediately. Hence, the second requirement is met as well. Concerning the trustworthiness of the integrity measurements we rely on the TPM to protect the integrity measurements from manipulations. As we have pointed out in Sect. II-A, an attacker cannot deny that a certain program has been executed as all executables are measured and the PCRs cannot be set directly but are always set to the concatenation of the old hash value and the new measurement value. We also rely on the tamper-resistant TPM to protect the cryptographic keys — withstanding physical attacks as well. However, we are aware that TARNOVSKY succeeded to read out a private key from a TPM [10]. As he pointed out at the Black Hat Technical Security Conference in 2010, the attack is very sophisticated and not that easy to perform. Furthermore, we required that applications provided by the bank must be isolated from applications provided by the ATM manufacturer — not only by means of the operating system (3)
6
and that applications provided by the bank must not get access to ATM hardware devices (EPP, card reader, and cash withdrawal component) (4). We proposed in our concept to have a basic system whose main task is the control of the other systems, i.e. the provisioning of virtual TPMs for those systems. There is one system, the manufacturer system, that is provided by the ATM manufacturer and that only houses applications that provide the basic ATM functionality. We pointed out that those applications are “critical” as they require access to the EPP, the card reader, and the withdrawal device — this system is the only one that gets access to those devices. The integrity of the manufacturer system is measured by the basic system all the time — not only during boot-up — and remote attestation towards the manufacturer is performed periodically by the basic system. In case of an integrity violation, the manufacturer informs the bank to put the ATM out of operation. Then, we proposed a bank system that is “open” for banks, meaning that bank administrators can customize the ATM by installing applications or presenting advertisement on the screen. This is basically a Windows system as it is used on nowadays’ ATMs with the important restriction that applications within this system do not get access to the ATM hardware devices. This system is protected via state of the art security suites — having built up a chain of trust up to this system, the bank knows that the security mechanisms are still running and that they are up-to-date. Thus we have met the third and fourth requirement as well. VI. R ELATED W ORK To the best of our knowledge we are the first to propose an integrity protection concept for Automated Teller Machines. Our concept is based on the TPM virtualization as presented by B ERGER ET AL . [8] and on the Integrity Measurement Architecture (IMA) as presented by S AILER [7]. S TUMPF ET AL . [11] present a concept for a trustworthy system architecture using virtualization. They propose not to attest the whole system state but rather attest trustworthy operations processes. Therefore, they employ trusted virtual machines. B ERGER ET AL . [12] have come up with an integrity protection concept for virtualized data centers. A Mandatory Access Control (MAC) policy that states which virtual machines are allowed to use which resources is enforced by the VMM. VII. C ONCLUSION AND O UTLOOK As we have shown in the last section, our concept meets all the requirements in terms of integrity protection. Attacks against the integrity of ATMs have already been performed. The provisioning of additional virtual machines on an ATM is also facilitated with our concept. Thus, innovative future ATM applications may be rolled out easier — at the same time maintaining the integrity of the whole system. When bank cards of estimated 30 million customers in Germany could not be read by ATMs due to a programming error within the cards’ chips in 2010 [13], the ATM manufacturers were called to provide a repair-application on their ATMs so that the customers could update their cards at the terminals.
Our concept would allow for a straightforward allocation of a virtual machine on the part of the manufacturer that only contains the repair-application — the system getting access only to the card reader and no other ATM hardware device. When we think of future applications that can be based on our integrity protection concept, we can think of a Soft PINPad. This Soft PINPad would be based on a multi-touch screen and the actual program logic would be implemented in software on the system computer. Today, such a user-friendly concept cannot be realized as the Payment Card Industry (PCI) would not certify such an implementation — the PINPad is a highly security-sensitive device that has to be particularly integrity-protected, as it is the case for state of the art EPPs. The ATM manufacturer could provide a virtual machine that only gets access to the input of the touch screen — and that is the only one that gets access, actually. The integrity of this system is permanently ensured by the manufacturer and thus, such a Soft PINPad, based on our integrity protection concept, would have good chances to get a PCI certification. R EFERENCES [1] ATM Marketplace, “ATMs reprogrammed to print out ATM, debit details on receipts,” Webpage, Jun. 2009, http://www.atmmarketplace. com/article.php?id=11060&na=1&s=2. [2] ——, “Reprogrammed ATM helps Minn. man get away with $7,400,” Webpage, Feb. 2009, http://atmmarketplace.com/article.php? id=10714&na=1&s=2. [3] ——, “ATM thieves take $60,000 from ATM after software is allegedly hacked,” Webpage, Feb. 2009, http://atmmarketplace.com/article.php? id=10703&na=1. [4] K. Zetter, “Researcher Demonstrates ATM ‘Jackpotting’ at Black Hat Conference,” Webpage, Jul. 2010, http://www.wired.com/threatlevel/ 2010/07/atms-jackpotted/. [5] Trusted Computing Group, “TCG Specification - Architecture Overview - Revision 1.2,” Tech. Rep., Apr. 2004. [6] Ruhr University Bochum, “TrustedGRUB,” Webpage, http://www.trust. rub.de/projects/trustedgrub/. [7] R. Sailer, “Integrity Measurement Architecture (IMA),” Webpage, http://domino.research.ibm.com/comm/research people.nsf/pages/sailer. ima.html. [8] S. Berger, R. C´aceres, K. A. Goldman, R. Perez, R. Sailer, and L. van Doorn, “vTPM: Virtualizing the trusted platform module,” in USENIX-SS’06: Proceedings of the 15th conference on USENIX Security Symposium. Berkeley, CA, USA: USENIX Association, 2006. [9] VISA, “VISA Europe Data Security Alert - Compromise of ATM PIN Transactions,” 2009. [10] The H Security: News and Features, “Hacker extracts crypto key from TPM chip,” Webpage, Feb. 2010, http://www.h-online.com/security/ news/item/Hacker-extracts-crypto-key-from-TPM-chip-927077.html. [11] F. Stumpf, M. Benz, M. Hermanowski, and C. Eckert, “An approach to a trustworthy system architecture using virtualization,” in Autonomic and Trusted Computing, ser. Lecture Notes in Computer Science, B. Xiao, L. Yang, J. Ma, C. Muller-Schloer, and Y. Hua, Eds. Springer Berlin Heidelberg, 2007, vol. 4610, pp. 191–202. [Online]. Available: http://dx.doi.org/10.1007/978-3-540-73547-2 21 [12] S. Berger, R. C´aceres, D. Pendarakis, R. Sailer, E. Valdez, R. Perez, W. Schildhauer, and D. Srinivasan, “TVDc: managing security in the trusted virtual datacenter,” SIGOPS Oper. Syst. Rev., vol. 42, pp. 40–47, January 2008. [Online]. Available: http://doi.acm.org/10.1145/1341312.1341321 [13] Heise Security, “Desaster mit EC-Karten kann teuer werden,” Webpage, Jan. 2010, http://www.heise.de/security/meldung/ Desaster-mit-EC-Karten-kann-teuer-werden-896988.html.
