You can download a copy of the whitepaper in PDF format here.
TPMs (Trusted Platform Modules) are tiny semiconductor devices that are embedded inside all PCs and are sometimes even implemented inside the CPU itself. They are a secure vault for encryption keys – similar in many ways to the chip on a payment card. TPMs have been shipped inside PCs and laptops for a long time, but they are not deployed properly in bank ATM networks, often due to the inertia in implementing new security architectures. This is surprising given that ATM networks need cryptographically-secure architectures more than most industries.
TPMs are, in fact, a lot more than just a secure key store. They are the root of trust for all security on PC-based networks – and should be so on ATM networks, too.
This paper explores what banks must look at when designing their ATM security architecture and how the industry should leverage the TPM to lockdown the hardware, software and the network ‒ cryptographically.
Everyone agrees that ATMs must be secured to the maximum possible extent without detracting from their usability. However, there appears to be less consensus on how this can be achieved. Of course, some of that confusion arises because of competition between vendors, with different security products vying for customer attention. But there is also a fair amount of misinformation that confuses customers and ultimately leads to poor implementations that are vulnerable to attack.
This whitepaper will pull together important fundamentals of system security, starting from the baseline of how individual computing systems should be protected and then addressing the unique use case of ATM networks which, of course, require the highest level of protection. Not only do ATM networks have responsibility for millions of dollars of cash, they are also a potential entry point to a bank’s host computer systems that can transfer large amounts of money around the world. A compromised ATM could be more costly to a bank than just the cash inside its safe.
First, let’s look at some common misconceptions about security. Perhaps the biggest misconception in system security is a misunderstanding of the concept of layered security. It is true that a single silver bullet does not exist when securing a complex system ‒ multiple co-ordinated locks are needed. However, that concept is often misunderstood to mean that the more obscure and complex the security, the more secure the system. This is simply not the case. There are fundamental cryptographic techniques that can be simple, openly discussed and well understood that must form the core of any security architecture. Not only do such techniques deliver quantifiable security, they are also easy to use, and do not rely on contortions from users to make them work.
Let us illustrate this with a quick example. We are all used to PC systems that require a username and password to log in. As the password-based security system came under attack from hackers, organisations created ever more complicated password rules that are highly unfriendly for legitimate users – regular password changes, no use of the last x passwords, complicated and difficult-to-remember password compositions, etc. Then Microsoft cut through all of that with “Windows Hello”.
Windows Hello combines TPM-secured cryptographically-safe hardware device recognition with biometric facial recognition. This is, in fact, very similar to a security concept that the ATM industry understands well – chip and pin. With Windows Hello, the chip is the TPM which is a cryptographic processor akin to the chip on a payment card, and the biometric information takes the place of the pin. Not only is this system more secure than any username + password system can ever be, it is also fabulously user-friendly. Not only can I log in to my Surface tablet by just looking at it, I can do so in an instant – faster than I can type a single letter of my password. Is it possible for a system to be both more secure and easier to use? Absolutely. We need to get away from the idea that there is no gain without pain – real security does not require torture for the user.
You would have noticed we introduced the concept of TPMs in the previous paragraph. This paper is built around TPMs as the “core root of trust” in computing. The TPM is a secure semiconductor chip consisting of a security architecture that was designed by the Trusted Computing Group (TCG) of over 100 companies, including major companies such as Intel, Microsoft, HP and IBM. Their work started as early as 1999 with the aim of creating a secure core for computing devices so that all computing security could be built from that secure core. The good news is that TPMs are completely standard in all new PC devices and have been for many years. The bad news is that many organisations do not even know they have this security jewel inside their computing devices and do not take advantage of it. This paper is an attempt at changing that situation – especially for our ATM industry. After all, we need secure computing more than most industries.
What does “core root of trust” mean and why is the TPM pivotal to computing security? To understand that, it is important to appreciate that all computing security relies on the clever use of encryption. Encryption is a computing method that converts data from a “clear” form to an apparently random form and back.
When data or information is in the clear form it can be used for an intended purpose. When data is encrypted it is unusable until it is decrypted. The crucial thing to appreciate about encryption and decryption is that a secure “key” is needed to encrypt or decrypt data. Without the key, the encrypted data is useless. Indeed, the word “key” in this sense is no different than a key to a safe. If the key to a safe is lost, you cannot access the gold inside that safe. In the case of computing, the gold is the data that is protected by the encryption process.
Now, the important thing to understand is that the key itself must be in clear form in order to use it to decrypt a message. That means that you need to have a way of storing the key securely. Yes, you can encrypt that key with another key. That would make the original key safe – but then you have a problem about where to store the second key. Indeed, you can have a chain of keys (and quite often there is such a chain). But the initial key must be stored somewhere safe in clear form. Where can you store such a clear master key inside a computer? The answer is not on the hard disk (or SSD). It is impossible to store a clear key on the drive securely – a hacker that can get physical access to the drive can always find the clear key. Software alone cannot protect it if an attacker has physical access.
Enter the TPM. The TCG designed the TPM as a hardware vault for secrets, and it is embedded inside the motherboard. In some designs, the TPM can be inside the CPU chip itself. It is designed for the exact purpose of storing keys securely. It is also a lot more than just a key store – and we will get to that in the next section. For the moment, consider that a computing system might have a chain of keys, but that the key at the start of that chain must be in the clear and must be stored very securely so that it can only be used for trusted purposes. The TPM is that key store.
I promised that the TPM is not just a glorified key store. Think about the very first problem that a secure key store has on its first day at work. If someone says to the TPM: “Please can I have that clear key?” how do you know who is asking for the key? It’s all very well to store a key securely, but to whom are you going to give that key? Is that a legitimate piece of code asking to use the key or is it some malware? Has a hacker modified the software on the PC with malware and then said ever so politely: “Please, TPM, can I use the key?” You see the problem – it is not enough just to be a super secure key store. You need to authenticate the software that is asking to use those keys. Enter now the TPM’s second party trick – core root of trust measurement (CRTM).
CRTM works with a chain of trust that begins at power-up. The hardware and the TPM work hand in hand to “measure” the boot sequence of the PC from initial boot and then to the BIOS/UEFI, and all the way to starting up the Operating System. It “measures” whether any of the software on the PC has been modified or tampered with during the start-up process. This process is best known as Secure Boot which today is a standard feature of new PC cores that use UEFI firmware to start up the PC.
To help with Secure Boot, the TPM design introduced a concept called PCRs (Platform Configuration Registers). PCR values are calculated by the TPM in a process called “extending the PCR” in a manner somewhat similar to creating a blockchain, resulting in the PCRs having a unique fingerprint (ie a set of hashes) of the start-up sequence of the PC. If the PCRs are unmodified from the past, the start-up software in the PC is then unmodified – and that is cryptographically guaranteed. It is impossible for malware to have modified even a single byte of the measured start-up software without impacting the PCR values.
This is a hugely important concept in cryptography. What is known as the “secure hash function” is an encryption-like function that converts a block of data to a fixed length string of characters that acts as a fingerprint of the original data. If the data changes, the fingerprint changes. This is therefore a sure-fire way of detecting even the lightest modification to a large body of software. The TPM uses a variant of hashing called an HMAC. An HMAC is a hash that is a “keyed-hash”, which means that only someone who has the right secure key is able to generate or verify the HMAC hash. It is a kind of “encrypted hash”.
There is a reason why we drilled down into this part in some detail. This is the way in which the TPM technology guarantees that the core software in the ATM is 100% secure. There is no way to modify even a single bit of software in the boot sequence of an ATM protected by a TPM without breaking modern cryptography itself. It is also the concept that we then extend in this paper to secure the whole of the rest of the ATM.
On a Windows 10 ATM, there are two important Microsoft technologies that take over at this point: Bitlocker and Device Guard (now known as Windows Defender Application Control ‒ WDAC). Bitlocker is Microsoft’s drive encryption technology. It is able to encrypt the whole of the hard disk or SSD, and most importantly saves its drive encryption key “in the TPM”. Actually, it is slightly more complicated than just saving the key in the TPM – we will shed a bit of light.
Keep in mind that it is not enough just to store keys securely, it is essential to work out “who” is asking for the key before handing it over. The TPM has another new trick called “sealing” the key. When the drive of an ATM is first encrypted in a safe environment, and a new key is generated by Windows, that key is then encrypted using a separate “key-encryption-key” called the KEK. The KEK itself is further encrypted in a process called “sealing” using the PCR values and a private key of the TPM. When the ATM boots, the KEK key becomes available only if all of the core software fingerprints measured by the PCRs have been validated – which means that the BIOS and the Windows code have not been tampered with, as explained earlier. Using the KEK, Windows decrypts its drive-encryption-key and uses that to decrypt the whole drive. Once the KEK has been retrieved, Windows closes the KEK door behind it. It does this by “extending” PCR 11 – which means that PCR 11 gets modified after the KEK is unsealed, so that nobody else can subsequently retrieve the KEK. The KEK is kept safe by the TPM until the next boot sequence and is made available again only if the PCRs confirm that none of the core software has been tampered with, and then locks the door again as soon as the KEK has been made available to Bitlocker to decrypt the drive.
As you can see, we have built up the core software step by step, checking each one using PCRs to ensure that no tampering has occurred, until we complete the boot process and load Windows. We now need to start-up the ATM application software and verify that all executables that we run have not been tampered with before we use them. In other words, we further extend the same concepts of checking the cryptographic fingerprint of every software component before we use it. This final part of the start-up chain is executed by Windows WDAC (or 3rd party software with similar functionality). This is often called whitelisting, and results in the hash (ie the computed fingerprint) of every executable being checked before it is allowed to run.
The best way to whitelist ATM software using Windows WDAC (or other whitelisting software) is to use what is known as a “certificate rule”. It requires that the software that you deploy on the ATM has been pre-signed by the developer of that software. So, for example, Windows 10 executables are signed by Microsoft with their private key. That means that anybody can verify that the Windows executables have not been modified or tampered with in transit and are in the identical state they were in at the time when they were signed by Microsoft, by simply verifying them using Microsoft’s code-signing public key. In order to get WDAC to confirm that, all that is needed is to create a “certificate rule” that says executables signed by Microsoft are safe to use.
Similarly, KAL’s software is always signed by KAL’s code signing private key. Our customers can verify that KAL software has not been tampered with by installing KAL’s code signing certificate on each ATM.
But what about other software that may not be pre-signed in that way? There are three options open to the bank:
- Get your vendor to sign their code.
- Fire the vendor. (Are there really ATM vendors that do not sign their code in the year 2020? Apparently, yes).
- Use a “hash rule”.
A hash rule is a rule that you add to your whitelist policy for WDAC whereby the bank calculates a hash for each of the files that are from a vendor that has not signed their executables. In other words, you do their code signing for them. Obviously, this is not as good as the code being signed at the origin, as any tampering that occurs in transit between the vendor and the bank cannot be detected (although there might be other mechanisms to ensure secure transmission).
A second downside with implementing it in this way is that the bank needs to create a “hash rule” for every executable file. This is far less elegant than simply installing the vendor’s public certificate in the ATM which then covers all executables from that vendor, including all future updates from that vendor.
Once we get to this point and the ATM is up and running, all of the software has been cryptographically verified. No executable that has been tampered or modified in any way is allowed to run. Not even a single bit of the gigabytes of software executables on a modern ATM can be hacked without being detected and blocked.
We are not quite there yet, however. An ATM protected in this way is bulletproof as far as unauthorized modification of its software stack is concerned. But that is not the end of the story. Injecting malware on the ATM is not the only method of attacking an ATM. We will now look at how the TPM can help with other types of attack.
The TPM is not just about securing the boot process of an ATM. It is the core root of trust that allows everything else to be secured, too. Let us turn to a fabulous book written by members of the Trusted Computing Group, Will Arthur, David Challener and Kenneth Goldman. The book, “A practical guide to TPM 2.0”, is outstanding and a treasure trove of ideas that inspired me to write this whitepaper. The book is free to download from here.
The best way to summarize this book quickly in this paper is to focus on the 53 use cases listed in the book. With permission from the authors, I reproduce their use cases below:
1. Storing boot parameters
2. VPN key access
3. Primary key optimization
4. Identity key provisioning
5. Permitting a resource manager to securely manage TPM keys
6. Attacker replacing a key at the same handle
8. Detecting a reboot between attestations
9. Hashing a large file
10. Trusted boot - 1
11. Trusted boot - 2
12. Multiple simultaneous TPM digest algorithms
13. Storing login passwords
14. Core root of trust signature verification
15. Multiple primary keys
16. Custom primary keys
17. Certifying a TPM quote key
18. Creating a certificate chain
19. Assuring that a key’s authorization requires a digital signature
20. Assuring that a key’s authorization requires a biometric
21. Assurance of non-volatile data
22. Quote equivalent for a non-volatile extend index
23. Storing a secret
24. Storing a certificate
25. Storing a common password
26. Storing a root public key
27. Storing an HMAC key
28. Revoking access to a key
29. Multiple-user key revocation
30. Secure audit log of CA key use
31. Additional PCRs
32. PCRs with different attributes
34. Write-once non-volatile index
35. Standard certificates
36. Write once, read always NV index
37. Securing a policy secret
38. Duplicating a set of keys
39. Sealing a hard disk encryption key to platform state
40. VPN keys
41. Securely passing a password from the OS present to OS absent environment
43. Detecting a reboot between transactions
44. No increment attribute PCRs for VMs
45. No increment attribute PCRs for audit
46. Creation of different SrKs for different users
47. A set of servers acts as one
48. What TPM am I connected to?
49. What is the state of an NV index, counter, or bit-field index?
50. NV index used as a PCR
51. Auditing the TPM used as a certificate authority
52. Using the TPM to secure an application audit log
53. Ensure that PCRs do not change during a command sequence
Please cast an eye over the use cases above. The first thing to appreciate is that TPMs are not just about securing the boot process. As we said earlier, the TPM is the core root of trust that allows each step of what we must do with ATMs to be secured, one step at a time. Of course, every use case above may not necessarily apply to our industry. And remember these use cases are about securing that item in a cryptographically secure manner.
So, let’s take an example ‒ #40 “VPN Keys”. In normal use, a VPN would be set up between an ATM and a server by installing digital certificates (ie signed public keys) on the two systems. But what happens if someone hacks the certificates? It is true that certificates stored in a TPM-protected Windows environment with the lockdown described in this paper so far would be unmodifiable. However, we can go a step further. The VPN keys can be sealed against PCRs using the TPM. That means that at the moment the VPN is about to be set up, the keys required to set up the VPN can be made available only if the PCRs are in the correct state. Any difference and the VPN connection is rejected. Now consider that this concept can apply to both sides of the VPN tunnel. Not only must the PCRs be in the correct state on the ATM-side, they also can be required to be in the correct state for the ATM server in the datacentre. If that is done, we would have cryptographically confirmed that both the ATM and the ATM server are in a secure state before connecting. We would know that all executables that have run on both the ATM and the ATM server up to that point are pristine and untampered with, and we allow the two to connect if, and only if, that scenario is met by both systems.
This whitepaper is not the place in which I propose to discuss all of the ideas in the eBook. Indeed, there are additional use cases that apply to ATMs specifically that need to be discussed, designed and implemented. I hope that the ATM industry will do that through one or more of its committees. More on that later.
The previous section touched on network security. Now let’s explore that in a little bit more detail as this is a use case that has particular importance to ATMs. It is clear that not only do we want ATMs to be individually secure, we also require that any backend server system that we touch is also secure and uncompromised. Please consider the diagram below:
The diagram shows the connection scenario in a typical large bank with sophisticated ATM services. The ATMs connect to a terminal handler that orchestrates the services from multiple backend servers. An HSM (hardware security module) provides cryptographic services and helps with pin zoning. Once a transaction has been staged and requires to be authorized, it gets sent off to the core banking system if it is an “On Us” transaction, or to the card schemes if it is an “Off Us” transaction.
Now consider a security Utopia where every ATM and every server has a TPM (which is the case for all recent hardware), all systems have been verified from boot with PCR measurements, and all TLS connections and VPNs have been set up using certificates unsealed by the TPM and are therefore cryptographically guaranteed to have not been tampered with. A Utopia indeed. The sad situation in August 2020 is that very few banks have achieved this level of security.
A potential implementation challenge here is scalability and clustering. How do you create a server cluster if connections are tied to individual TPMs? See use case #47 above “A set of servers acts as one”. The TCG already thought of that.
This paper has so far focused on the PC-core of the ATM and how to ensure that the software is malware free after start-up and during its operation. Now let’s turn to the individual hardware devices inside the ATM – the card reader, the pinpad and, of course, the cash dispenser. What is the security situation with the connections between the PC-core and the individual devices? On most ATMs these connections are USB connections that can be physically tampered with. If these connections have clear data, the ATM is vulnerable to attack – even if it is free of malware. Let’s discuss this again with a diagram:
As you can see, I have drawn the USB connections as a cloud to indicate attack risk. The TPM secures the PC-core, but the USB cables are at risk from attack if they are not protected. Arguably, these connections are the responsibility of the ATM hardware vendor to protect. However, the situation is not quite that simple as it also depends on interoperability requirements between the hardware devices and the rest of the system. For instance, if the messages to the CDM (cash dispenser) are encrypted end-to-end, where should that “other end” be? If the other end terminates at the terminal handler, for example, a lot of interoperability requirements need to be discussed and agreed.
It is also clear that even the cash dispenser is not yet well secured on many ATMs – witness the various “blackbox attacks” in media reports. An ATM blackbox attack occurs when hackers intercept the connection to the CDM and dispense cash using their own PC core. Most modern ATMs have an encrypted connection from the PC core to the CDM, but KAL suspects that the security design leaves a lot to be desired as some of these ATMs do not have TPMs. Let’s be very clear: No TPM = No Security. Obscure ways of encrypting the connection using keys that are protected by magic is not security. It is obscurity and hope. If your hardware vendor cannot publish information about how encryption keys are protected, be very clear that that is because the keys are not properly protected.
The good news is that the ATM industry’s XFS committee is discussing how the next generation of ATM devices should be protected. Some of you may have heard of the forthcoming release of XFS 4.0 which has been named XFS4IoT. The IoT part demonstrates the intention of the spec to be ready for the modern IoT world. There are several major goals for XFS4IoT:
- The spec is Operating System agnostic. It means that ATMs can have Windows, as well as Linux or any other OS, inside the ATM.
- It is cloud friendly. ATM devices can expose services directly to the cloud. The brains of the ATM can be in the cloud and not just inside the ATM as it is today. For example, the card reader could expose card reader services to the cloud. The cash dispenser could expose cash dispense services to the cloud.
- Web services exposed in that way must be secure. XFS4IoT will have built-in security to ensure end-to-end security for the devices. The transport protocol has been selected as Web Sockets secured by TLS with certificates on both side. In addition, each XFS4IoT device can have a hardware secure element to allow end-to-end security for the connection. That connection can terminate inside the ATM itself (as is common today) or it can terminate on a cloud server.
The diagram below demonstrates the concept:
XFS4 ATMs can be designed like the conventional ATM on the left-hand side of the diagram where devices connect to a software application on the PC-core, or can expose a secure service to the cloud like on the right-hand side. In the second case, there may not be a PC-core at all inside the ATM and each device might be completely independent of each other, but physically close and working in tandem, orchestrated by the cloud application.
The most important thing to note are the boxes labelled “HSE”. HSE stands for “hardware secure element” and the XFS specification, of course, leaves it open for hardware vendors to determine how best to implement it. It is obvious that the HSE needs to be either a TPM or contain a subset of TPM features. As a minimum, the HSE needs to be able to:
- Store private keys securely
- Implement a basic “core root of trust measurement” (CRTM) to ensure that only secure firmware can use the HSE
- Implement encryption and signing services
KAL has discussed this with the TCG committee and they indicate that they would be delighted to help the ATM industry brainstorm the options. Indeed, the TCG already has made some progress with “mini TPM” concepts. One is the TCG’s DICE design and the other is the TCG’s MARS design. Are DICE and MARS ready for use in the ATM industry? We need to find out.
An interesting thought here is whether standard TPMs could be used as the HSE inside each device. From a cost point of view, the answer may be yes – TPMs cost less than 1USD in OEM volume. DICE could cost even less. For our industry that protects millions of dollars of consumer funds, the cost of a TPM or other type of HSE is unlikely to be the blocker.
We discussed device protection in the previous section, but there is one unique device we need to highlight in the context of security, and that is the EPP (encrypting pin pad). The EPP is, in fact, an independent root of trust inside the ATM. It is highly secure, is regulated via the PCI PED requirements and each EPP is individually managed and tracked on a global basis by the industry. It has its own CRTM measurement of its own firmware and auto-destructs if tampering is detected. It is very secure indeed.
However, the EPP has been a pro and a con for the industry. As the EPP provides a certain level of security for ATMs (we will discuss its limitations in a moment), banks have relied on it to secure ATM transactions. The EPP stores the bank’s master key securely, and using a chain of keys ensures that the pin block is secure and communication messages between the ATM and the host are encrypted and MAC’d. This is good security. However, it is not sufficient security.
The EPP is unavailable when the ATM boots and remains unavailable until Windows has booted and XFS SPs (the ATM’s hardware drivers) have started up. That means that the EPP has nothing to say about the validity of the software inside the ATM. If a malware-infected ATM application wishes to accept a pin or MAC a message to the ATM host, the EPP will do its bidding. The EPP’s protection perimeter is too small to be able to help secure the whole of the ATM. It is a gem of security in a mass of potentially unprotected software where there is no TPM.
The reader perhaps thinks at this stage that if it is impossible to change any software inside an ATM protected by a TPM, it will be difficult to carry out valid software updates. Remember that the application software is protected using a certificate rule. It is signed by the application developer (which could be the bank itself or the bank’s trusted vendor). All that is needed is for the updated software to be signed with the secure private key of the software development organisation, and the ATM will accept the change. It is as simple as that.
Changes to the core software measured by the PCRs needs an extra step. The core software can be updated completely remotely without a technician visit but requires a temporary key to be created during the installation process that is sealed against the unchanged PCRs. Once the installation is completed, the new keys are sealed against the full set of PCRs. Easy.
Remember our earlier example about Windows Hello – good security does not need to be difficult to use. In fact, world-class security – which is what TPM protection gives banks – is easier to use as well as being cryptographically secure when compared with traditional methods.
Although we haven’t specifically said so before, much of the discussion above is about protecting the ATM from both physical and software attacks. A common attack method on ATMs is to remove the drive, modify the software and restore the changes on to that ATM as well as other ATMs. That method of attack is not possible if the drive is encrypted and the boot chain is protected by the TPM.
Another type of attack is to attempt to “brute-force” the TPM and try various keys in quick succession. The TPM has built-in “anti-hammering” protection that blocks this.
Finally, there are certain other types of extreme attacks that could involve direct interference with the motherboard electronics. Such an attack would be expensive to undertake as it requires specialist equipment and has not happened up to now, as far as we are aware. However, there are low-cost ways of protecting against such attacks, such as the use of resin to protect exposed electronic connections on the motherboard.
Securing ATMs and PCs with TPMs as the root of trust is the only known and published way of fully securing computer systems. Our industry should ask itself why TPM-based security is not more common on ATM networks. Of course, different companies will want to compete in the market place and they will want to position their security products. That is to be expected. But it is very important that banks do not fall for illusory solutions. Here is a list of things to look out for:
Myth: “No need for a hardware secure element”
Be very clear that it is impossible to store private keys on the disk/SSD of an ATM securely. The reason is that however long the key-chain may be, there has to be an initial clear key. If that key is “hidden” on the drive it can always be recovered. Some solutions claim to generate the key at start-up. But remember that clear code is needed to generate that key. It has to be in the clear as we have not yet decrypted the drive. If it is in the clear, it can very simply be reverse-engineered from the executable code which will be in the clear before decryption of the drive.
Think about this another way. If it was possible to hold keys securely in an ATM using software techniques alone, our industry would not have gone to the trouble of building EPPs…
Myth: “No hardware secure element is required as the keys are stored on the network”
If the ATM is not secure enough to hold the keys securely because there is no TPM, it is not possible to solve that problem by moving the keys to a network location. Here is why: when the ATM boots up, it needs to access the network to obtain the secure key. It then does not have a cryptographically secure way to authenticate itself on the network because it has no key store. That means the network server does not know “who is asking for the key”. For example, when Bitlocker stores keys on the network, it still needs a TPM to authenticate itself to the network. No TPM = No Security.
Myth: “No need for encryption keys”
The vendor claims that storing keys is unnecessary because they have magical technology that allows encryption to happen without keys. Well, that would indeed be too good to be true. Why has the world forever struggled with Key Management techniques when you do not need keys? All known encryption techniques such as 3DES, AES and RSA require private keys. The private keys are called that as they must be stored securely. What makes an encryption system secure is that the keys are chosen from a truly huge number of possibilities. For example, 3DES has at least 2112 keys. It would take 30 years to try all keys if they were attempted at the rate of 5 billion per second. With AES it would take 1022 years at the same rate.
Myth: “Our algorithm is confidential”
Real security is built on open standards and open algorithms along with confidential keys. The only aspect of a security system that should be confidential is the keys. If the keys get compromised, you change them, and the system is secure again.
Myth: “Access control lists (ACLs) keep us safe”
Access control lists are easily circumvented in the absence of a TPM lockdown. There are various other drawbacks to ACLs too, which we will not delve into here, but suffice to say that ACLs by themselves are insufficient protection for ATMs.
I hope that the reader has arrived at an appreciation of why the TPM is pivotal to computing security and therefore pivotal to ATM security. I hope it is also clear that most banks have still some way to go in securing their network in a cryptographically guaranteed way. It is also important to note that any such security system has to be designed with interoperability in mind. As multiple vendors and multiple product solutions are a standard part of the modern ATM technology landscape, it would not be possible for lockdowns to be implemented by each vendor independently. That would create an ATM that is unusable.
I hope that this document is the beginning of a process that will allow interoperable security specifications to be developed using the cryptographic foundations available to us from TPMs. The Trusted Computing Group has offered us their help. It is now up to our industry’s various committees – XFS4IoT, ATMIA and EAST – along with banks and vendors to design the way forward.
I would like to thank the following people for their contribution to this project:
- Michael Moltke (NCC Group Denmark)
- Kit Patterson (KAL)
- Will Arthur, David Challener and Kenneth Goldman for writing the eBook on TPMs, and David Challener for organizing support from the TCG