Apple has announced Apple pay a new payment system that could solve some problems. Especially the become in the United States become a major problem attacking the credit card information in the point of sale are in Apple Pay is not impossible, but futile.

On September 9, 2014 Apple introduced together with the presentation of iPhone 6 and iPhone 6Plus be payment system Apple Pay. Apple Pay was introduced first in the United States. Nine months later, on 14 July 2015 it was finally time also in Europe and Apple Pay was in Britain at the start - in more than 250,000 stores, restaurants, gas stations, post offices and public transport.

The following description is based on the published information on the website of Apple, in a support document, and in iOS Security Guide, edition October 2014. The description is divided into three parts: First, get to know the components involved. After activating Apple Pay and finally follows the payment in a shop. The also possible use for payment in Apps is described in the box. Finally, it comes to the question of how safe is it everything.

Payment within Apple Pay apps

Payments within apps are handled via the Apple Pay server. Apple Pay stores this anonymous transaction information such as the approximate payment amount. This information can not be traced back to the user and contain no information about what the user has purchased. The settlement of payments via an API and requires the specification of a Merchant ID (Merchant ID) that uniquely identifies the merchant behind the app, and will be applied to the payment information.

The beginning of the Apple Pay: payment

Requires an app a payment, it first checks via the API, if the iPhone Apple Pay supports whether it is activated and if the payment service used for this is accepted by the merchant. If a payment is possible, the app for the necessary information, such as billing and shipping addresses and contact information, together. Thereafter, calls on the App iOS to display the Apple Pay dialogue, displaying all relevant information for payment.

Where the user of the payment by the Touch ID or passcode to, all information displayed on the Apple Pay dialogue are communicated to the dealers.

The actual payment

After the user has authorized the payment, a cryptographic nonce value is requested by Apple Pay server that matches the nonce provided in the payment business in the NFC terminal merchant. then all required information is summarized from the Secure Element and encrypted with the key of the Apple Pay server As with the payment in the business. Thereafter, the data is sent to the Apple-pay server, which decrypts the nonce checks and encrypts the data in case of success with the members of the Merchant ID Merchant Key.

The re-encrypted payment information is then sent back to the iPhone, which forwards them to the app via the Apple Pay API. The app turn forwards the data to the server of the dealer who decrypts and further processed. As in the case of a payment transaction can it be made to the existing infrastructure for payment by credit card again.

Protection of additional data

Apart from the payment information needs to send additional information, such as order numbers or customer number to the seller the app in general. To protect this data from being tampered with, the app can let signatures via the API from the Secure Element.

A hash of this data is added to the encrypted payment information. The merchant can therefore check if necessary, whether the data supplied to it by the app are intact.
Let's do it with us (it) ...

to describe Apple Pay in all aspects, is beyond the scope of the article quickly. Therefore, some simplifications are needed.

To enable Apple Pay is either a registered iTunes Store credit card added to Passbook or the data of a new credit card, either typed or the card simply photographed with the iPhone. In the description, I go out from photographing the map since incurring the most data.

When I write iPhone in the description of payment in shops, I mean even the iPhone, because so far does this payment with Apple Pay only with the iPhone 6 and 6 Plus. The Apple Watch there are not yet, and until it appears, it may well come to changes to the previously planned functions and processes.

but in the case of payment within apps that described above applies analogously for iPad Air 2 and iPad mini 3, although I for simplicity hereinafter referred to as write iPhone there.

And when I write bank so is also the respective payment service provider, such as the credit card company meant if there is one.

1. The components of Apple Pay

In iPhone more components are essential for the function and safety of Apple Pay. Let's start with the hardware, which is also shown in Figure 1:
The Secure Element

The secure element is an industry standard for the secure storage and management of sensitive data. In a certified microcontroller with the requirements of the financial industry running corresponding Java Card platform for electronic payments. In the case of Apple Pay on running applets for managing Apple Pay, and certified by the PSPs Payment applets. The data required for payment will be by credit card company or issuing bank with just them and the payment applet known keys encrypted sent to the applet in the Secure Element. They are managed by the applet and protected by the protective measures of Secure Elements.
The NFC controller

The NFC controller is the one for the communication of the iPhone with the point-of-sale terminal in the business over the minutes of the Near Field Communication responsible. During a transaction, the terminal communicates in the business over the NFC controller directly to the Secure Element. NFC controller and secure element are connected via a separate hardware bus directly to each other, so that iOS has no access to the transferred data.

Secondly, the NFC controller wrapped in the payment within an app communication between the app and the Secure Element from.
The Secure Enclave

The Secure Enclave is a specially protected area within the iPhone processor and managed generally every authentication process on the iPhone. In her are stored as well as the fingerprint data for the Touch ID. It is responsible for the authorization of a payment transaction in the case of Apple Pay. Only after the user a transaction approved by the Touch ID or passcode, clear the payment is initiated and passed control to NFC controller and secure element.
The connection of Secure Enclave and Secure Element

Secure Enclave and Secure Element communicate via a serial interface; the secure element is additionally connected to the NFC controller, which in turn is connected to the application processor.

Secure Enclave and Secure Element can also no direct connection securely communicate with each other, because the connection with an installed during the manufacturing process common pairing key is encrypted. This key is calculated from the Secure Element from the UID key and the unique identifier of the secure elements and transferred to the factory in a secure way in a Hardware Security Module (HSM), from where it is then transferred to the Secure Enclave. Encryption and authentication are based on AES, which come on both sides cryptographic nonces to protect against replay attacks used.

The "Authorization Random" - (AR) value

No part of the hardware, but an important constant is the "Authorization Random" - (AR) value. It is produced in the Secure Enclave, when the user uses a credit card for the first time, and is persistent as long as Apple Pay is activated. When he is sent to the Secure Element, it is encrypted with the pairing key; in the Secure Enclave, he is protected by the encryption and anti-rollback mechanisms against spying. Receives the Secure Element a new AR, all previously added maps are marked as deleted.

To secure element added credit cards can be used only when the secure element is authorized to do so with the same pairing keys and AR, which were used when adding the map. This allows iOS to let make the cards of the Secure Enclave unusable by the AR is marked as invalid. This is necessary if

• the passcode is turned off 
• the user logs out from the iCloud 
• the user deletes all content and settings 
• the iOS device is recovered in recovery mode
  

Apple Pay comes naturally not without software. Besides the already mentioned apps of different payment service provider in the Secure Element that is the Passbook app.
The Passbook app

As part of Apple Pay Passbook accepts adding and managing the credit and payment execution. The user can, for example, consider in Passbook his credit card details and additional information such as the terms and conditions and privacy policy of his bank or the last payments, add new credit cards to Apple Pay or make payments in shops or Apps.

Apart from the iPhone and the software that runs on servers also are involved in the function of Apple Pay.

The Apple Pay Server

The Apple Pay server manages the status of the activated in Passbook credit cards and the data stored in the secure element Device Account Numbers (see below). The Apple Pay server communicates with both the iPhone and the servers of banks and mediates between the two. He is also responsible for re-encryption of payment data for payments within apps.
The bank server

The bank server have two purposes: First, they are responsible for the release of the credit for Apple Pay. A new credit card can only be used with Apple Pay, unless authorized by the issuing bank. Secondly, they naturally develop from the payments.

When making payments in shops the existing infrastructure for processing credit card payments on the merchant website used. The data is sent over to the bank server, the payment then performs (or denied on misuse). Here, in principle, come the same procedures as for credit card payments used, only that the customer is not identified through his credit card details, but Apple Pay.

2. How to Activate Apple Pay

To communicate with the bank Apple Pay uses two server-side views, "Check Card" and "Link and commission". The bank can also check cards, approve and add to Apple Pay. The communication is encrypted using SSL.

To enable Apple Pay the card is simply photographed with the iPhone. The Passbook app then attempts to detect the name, the card number and expiration date. The photo is not saved on the device yet added to the photo album. If all fields are filled in, checks the "check card" process the card number and the expiration date, which is then encrypted is sent to the Apple Pay server.

The "check-card" process may then return a "terms-and-Conditions" ID, whereupon the Passbook app loads the additional terms and indicates to the user. Accepts these conditions, is the ID of the accepted conditions, together with the information required by your users Card Verification Value (CVV, the security code of the credit card, which must be entered by the user during online use to prove that he really be the map) sent to the "link-and-commission" process. The will also receive some information about the device such as the last four digits of the phone number, the device name and the current location of the device, rounded up to integers.

The collected data from the "Link-and-commission" process encrypted sent to the bank, which decides on the basis of this information whether the credit card for Apple Pay may be used. If a bank customer, for example, usually staying within the United States and perhaps even decide with a newly purchased iPhone to activate Apple Pay during a Russia holiday and that activation of this test might fail.

The "Link-and-commission" process ends with the download of the credit card representative Passbook pass file on the device as well as the binding of the card to the Secure Element.

The passport file contains the URL for downloading a map image and metadata such as contact information, the associated Bank app and supported features of the card. It also contains a status field that contains information about whether the personalization of secure elements has been completed, the card is currently locked by the publisher or if prior to the use of the card by Apple Pay an additional verification, for example, by a text message, an e- mail, a phone call or the like, is required. The process of activation is summarized in Figure 2.

The Device Account Number

Grants the Bank its consent to the use of the card, it generates a unique, device-specific Device Account Number, which is encrypted and stored along with additional information, such as the key to generating transaction-specific security code in the Secure Element on the iPhone.

The Device Account Number is unique and linked to the iPhone and the credit card, thus identifying the originator of a payment clearly. It is insulated from iOS and is never stored on the Apple Pay server or in iCloud backups. Apple does not save the credit card information and has no access to the data stored on the device.

To facilitate the administration of the card by the user (somehow must indeed possibly of several offices for Apple Pay Credit can choose the desired date), Apple Pay, however, stores parts of the credit card number and the Device Account Number along with a description.

Deleting credit card from Apple Pay

The user has several ways to remove the activated for Apple Pay Credit. On the one that goes directly through Passbook, the other remote via Find My iPhone or iCloud settings. Activated by Find My iPhone the "Lost Mode", Apple Pay will be disabled.

In addition, there is also the possibility of using the "all data and settings delete" the entire iPhone or delete Find My iPhone. Then, the secure element is instructed to select all cards as deleted, so that they can no longer be used. The next contact with the Apple server Pay the credit card will be deleted from the Secure Element. Regardless marks the Secure Enclave the AR as invalid, so that no more payments can be authorized for the credit thus installed. The same thing happens when an iPhone is restored in recovery mode.

3. Payment in business

When paying in the terminal business merchant via NFC communicates with the previously held iPhone, which then displays the default credit card and the amount to be paid. Payment is made only when the user has confirmed them on the Touch ID (the default method) or entering the Passcode.

The passcode can always be used regardless of the default method. In certain situations, it is imperative, for. Example, if Touch ID is disabled or is not enabled for Apple Pay, or after five failed attempts with the Touch ID. After three failed attempts with the Touch ID, the passcode is proposed, but not yet enforced.

After the user of the payment has agreed to be of the Secure Enclave for authorization data on the type of authentication and details on the type of transaction (in this case "non-contact" as opposed to the use within apps), linked to the "Authorization Random "- (AR) value, signed sent to the Secure element. The Secure Element checked with the pairing key and his copy of the current AR, whether sent by the Secure Enclave authorization is correct. Only if this check is successful, the payment applet for contactless payment is enabled.

The Payment Applet now generates a transaction-specific security code, the part is like the Device Account Number for each payment. To calculate this only once valid codes of this stored during activation of the credit card in the payment applet key is used, which is known except the applet only the bank. The calculation includes among others the following data:

• an incremented with each new transaction counter 
• a random number generated by the Payment Applet 
• a random number generated by the NFC terminal
  

The security code, the Device Account Number and any other needed for payment data is then sent via NFC to the merchant terminal. From there, the payment will go the normal way of a credit card, while the credit card data is transmitted just without that.

The Bank may use the Device Account Number identify the payer and verify the payments with the security code. The code must belong to the specified device and be unique. A replay attack, are re-transmitted in which recorded transactions, so it is not possible.

What data gets Apple Pay?

A portion of the transmitted data has been already mentioned above. A summary is attached but still. Apple gets in the use of Apple Pay the following data (or in some cases, explicitly not), but according to Apple, not all will be saved: 

When you activate a credit card

• when you add a credit card using a photo, the image is analyzed locally on the iPhone and is neither stored on the Apple Pay server sent yet in the Photo Album or elsewhere on the device. 
• The credit card information will be forwarded to the bank server, but neither stored on the Apple Pay server yet on the iPhone. 
• The Device Account Number is stored element in the secure, where it is isolated from iOS. It is therefore not stored in iCloud Backup. Apple she learns during the payment within apps, but does not save it.
  

When paying in business

1. Payment is made between iPhone and NFC terminal of the dealer; Apple Pay server is not involved. 
2. Date and time of use, and the location (if location services are turned on) is sent anonymously to Apple Pay server. As usual, in order to improve this information with Apple Pay.
   

 When paying within an Apple Pay app

Since the Apple Pay-server encrypted payment information, Apple can read all the information contained therein as the device account number and the payment amount. These data are not evaluated.

Now we come to safety, starting with:
Protection of credit card information ...

The credit card data could be spied in several places: In the iPhone on Apple's servers Pay, traders and banking as well as during the transfer between these sites. Consider at the different options in more detail.
... During activation

As part of the activation of Apple Pay the credit card information of greatest risk are exposed, since they are both on the iPhone than be transferred over the network. On the iPhone, the data could be spied from injected malicious software, one that so far only one exception, however, are only available on devices with Jailbreak [1].

When installing a jailbreak the user deliberately avoids any existing safeguards and is responsible for the consequences alone. The exception mentioned above is on iOS devices installed on Enterprise Certificates under the WireLurker attack without jailbreak threat. And that is only active when the user explicitly allows, which he in turn is your own fault.

In addition, the introduced malware then also has to get to the sandbox with the Passbook app access to access to the processed data thereof. Or the memory of the iPhone camera, there to see the picture of the credit card spy - both no trivial operations. So I think this danger can be ignored until the emergence of new attacks or vulnerabilities.

Let's talk about transmission of credit card data. Since this is protected via SSL, here are the usual attacks, for example, by a man in the middle or a compromised server, possible. However, they are just as possible if the credit card data is transmitted, etc. in the conventional use of the card to pay in stores. In this respect there is therefore no real new threats, quite the contrary: With Apple Pay the credit cards are only transmitted during activation, then never again. In addition, they are only sent to the Apple-pay and banking servers, not to some merchant server. Overall, there are so much less opportunity for an attack.
... When paying

The greatest risk when paying with a credit card is that the card data be spied and abused. Even if the user replaces the harm suffered, he has a lot of trouble by the abuse.

In the US, this risk is particularly acute for some time because there are now specialized for the attack on the Point of Sale malicious software [2]. The only two tasks: the point of sale as long as possible unnoticed to compromise and to send all running over credit card details to the cybercriminals. And that has been folded several times in shockingly large extent.

In Germany, such attacks are not yet occurred, as is paid here rarely with the credit card. But the much more frequently used bank cards are not without danger; there have been attacks from compromised card reader.

Before these attacks, the use of Apple Pay is an effective protection: As the credit card data is not transferred, they can not be spied on. And if the cyber criminals spy on the Device Account Number instead used, they have none of it, because every transaction must be authorized with the transaction-specific security code. Den also spied value can cybercriminals not reuse, and a new they can not create, because of using a only the iPhone and the bank known key is generated.

The same applies analogously to an attack on the payment within apps: If cybercriminals compromise the merchant server, you can find there, as in the case of the point of sale no usable for carrying out unauthorized payments data.

In general, the replacement of the credit card data is designated by a value other than "tokenization", the replacement value accordingly as tokens. The credit card company for some time been working on developing their own solutions, but Apple quickly and then ship additionally a universal solution.
... On iPhone and servers

The credit card data is stored in the use of Apple Pay neither the iPhone nor the Apple Pay server. For Apple, the data, however, are stored; if the user is using his credit card for payment in iTunes, app or Mac App Store, it is indeed necessary for the processing of payments.

The bank server know the credit card anyway, so here comes the use of Apple Pay no new point of it.

In the case of the merchant even a point of attack falls away: While these will need to save with credit card, the credit card data in the payment, they find it not in the use of Apple Pay only.
Abuse of Apple Pay

Can Apple Pay are abused? With many other contactless payment options, such as the RFID-based bank cards, payment without user interaction when the card is brought to the RFID readers of Business close enough. In contrast, the user of the payment by Apple Pay must explicitly agree.

Consider the two possible attacks:

First, the use of a malicious reader, with a criminal empties the cash cards of all close enough coming people. In November 2014 was even shown for the usual UK RFID-based cards such as the limit in force there can be 20 pounds circumvented by withdrawals in a currency other partially. Such attack fails in Apple Pay on the necessary authorization of the payment by the user. Secondly, the abuse of a stolen card or a stolen iPhones. A working without authentication card could be abused to the consumption of the existing credit. But whether a wallet with 20 euro cash or charged with 20 Euro cash card is stolen, does not matter in this respect.

Which brings us to the possible abuse of a stolen iPhones. First you need to enable the use of Apple Pay the Touch ID or Passcode; So the thief would have to first time obtain access to the device before it can Apple Pay abuse. If he does know the passcode or determine or outwit the Touch ID, he would not only gain access to the iPhone, but could also use Apple Pay.

The fact that the Touch ID is not insurmountable, was demonstrated shortly after the presentation of the new equipment. This was also the case of the iPhone 6 otherwise (text / video) here even with a finger dummy, which has already works on iPhone. 5 The attacker must however have a very good fingerprint of the user to use it as a starting point for his dummy. And he needs to come off for now. The blurred residues on a stolen iPhone will be appropriate in most cases.

For casual thief the effort for an attack should therefore be too great, and for the more organized criminals it is too small. This think big and peeking masse credit card data, which are then written on blank cards and used in any other country, to withdraw money from ATMs. Individual iPhone that can not be easily deleted this from afar, are much too small a fish for her.
Attacks via NFC

How safe is the communication via NFC? Already 2012 Ecardgrabber for Android was developed which can spy transmitted via NFC credit card data when the Android device comes close to the NFC terminal or communicating therewith smartphone to a few centimeters. 2013 has bridged approximately 90 cm by NFC a researcher. This facilitates attacks on systems in which payments without user interaction are possible, bringing the attacker in the case of Apple Pay but also no closer to his goal. Because Apple Pay makes payment yes only if the user authorizes. At what distance from the transaction was triggered, it does not matter. And the spying of transmitted data is not a problem for Apple Pay. As described above, the ausspähbaren data for the criminals are worthless. Another problem are attacks on NFC, the weaknesses in the driver of the controller or the other about accessible software exploit. Charlie Miller warned, for example, at the Black Hat USA 2012 "Do not Stand So Close To Me" and published an analysis of the attack surface of NFC. And when Pwn2Own Mobile Competition in 2014 was twice the NFC Samsung Galaxy S5 and once successfully compromised the LG Nexus. 5 For the iPhone attacks NFC time were not an issue, since only the iPhone 5 was as the destination. NFC was indeed introduced with the iPhone 6, and iOS and have to prove next year only times that they better resist attacks than its competitors.

However, there is for the attacker while still to master another potential hurdle: At least so far NFC is reserved in the iPhone only Apple Pay. The attack surface is thus significantly lower than in devices that make NFC a variety of services available so but of course much more interesting.

But even if attacks are being developed, it does not mean that they are also "in the wild" occur, because it should not underestimate the "N" in NFC. A criminal must generally fairly close to his victim zoom before he can launch an attack on NFC. Or he may have to compromise a trader terminal and prepare so that it engages the iPhone during use. This is not impossible, but connected with some effort. Attacks on NFC I guess therefore indeed as possible in principle, retain it "in the wild" but very unlikely.
Conclusion

Apple Pay is a very well-designed solution that can make especially with the problem of scouted credit card data in the US circuit. From a security perspective there is nothing wrong with it; how it looks with the Privacy Policy, remains to be seen. Just because Apple says you saves almost nothing, that does not necessarily remain so yes. But in this respect is in paying the business anyway cash the only truly safe solution, because only thus can be paid anonymously. Online always leaves a payment tracks, the only question is where and how many. And Apple's solution seems quite economical with the stored data.