I try to figure out what kind of encryption the EMV standardization recommends for transferring payment information via NFC. I browsed through the specification, but I can't find any hint about this topic. I know though that the card manufacturer provides some encryption technology on their card itself, which has partly been compromised.
Does someone know, if its encrypted at all (I hope so) and if so, with which technology?
The communication between the card and the contactless reader is not encrypted.
You can easily eavesdrop and record the exchanged APDUs, I do it almost daily using a contactless spy (the Fime SmartSpy one).
But recording the dialog is not enough to clone the card.
You will get access to some information (ex : the card number, the track2 equivalent data), but :
you will miss information required to create a magnetic stripe card
you won't have the CVV (number written behind the card) required to make online purchases.
You also won't be able to "replay" the transaction because the transaction data includes two unpredictable numbers generated by the terminal and the card, which are unique to each transaction and signed by the card.
The private key/certificate used by the card to sign the transaction is never transmitted during the transaction and cannot be accessed.
That's this private key/certificate which is protected and encrypted on the card (I don't know the details of the security mechanisms).
The cards whose security has been compromised are some basic MiFare cards. These cards are not used for payment applications.
Simple answer: EMV transactions are not encrypted over NFC.
More specifically, a typical contactless EMV transaction works like this (very simplified, more commands are involved, but this should be enough to get you an overview):
Select EMV payment application.
Read card data. Card data is transfered in clear text.
Send transaction data (amount to be authorized, transaction date/time, ...) in clear text to the card.
Card generates a digital signature over the transaction based on its secret key (that's were cryptography comes in).
Terminal and/or backend verify the card's digital signature over the transaction data.
Btw. the paper you refered to ("Algebraic Attacks on the Crypto-1 Stream Cipher in MiFare Classic and Oyster Cards") is completely unrelated to EMV payment cards. The paper is about weaknesses of MIFARE Classic cards. As opposed to EMV payment cards, MIFARE Classic cards are simple contactless memory cards with some encryption and authentication logic.
Related
I want to know if my BLE 5 (low energy, not "typical"/core bluetooth) embedded system uses (preferably asymmetric) encryption, if encrypted at all.
I'm using this ble module that is communicating with an SOC. My SOC is capable of encryption but the FAE of the BLE module product couldn't come up with any useful information.
My program doesn't appear to have a bonding/pairing process, but I could be wrong since I did not take a closer look at the HAL layer program.
My question is, does BLE 5 require encryption?
If not, how do I find out if my connection is encrypted or not, using methods other than sniffers? For example are there any steps which must be gone through to facilitate encryption, in which case I should check if these steps were skipped or not? (If skipped then surely my communication is in plain texts).
ETA: The target BLE module is based on nrf52832, don't know what BLE stack/softdevice they are using. My soc is STM32WB55 series, using a rather comprehensive BLE stack that supports most functions of which name I couldn't recall for the moment.
BLE does not require encryption for a connection to be made.
At first, every BLE connection starts in Security Mode 1, Level 1 which does not use any encryption at all. Every message will be sent in cleartext. To increase the security two devices have to "pair". Security keys are exchange during the pairing process. There are multiple different pairing methods with different requirements. Have a look at this article for a starting point.
The pairing process is usually not started manually but automatically as soon as a device tries to access a secured characteristic. If you are using a phone to access such a characteristic you will be prompted with a pairing request popup. Based on your description I would assume that your connection is currently not encrypted.
To enable encryption on your SoC please have a look at the function aci_gatt_add_char. This document (direct download link) refers to this function on page 55 and shows that it takes Security_Permissions as an argument. The next page states the possible options as:
0x00: ATTR_PERMISSION_NONE
0x01: Need authentication to read
0x02: Need authorization to read
0x04: Link should be encrypted to read
0x08: Need authentication to write
0x10: Need authorization to write
0x20: Link should be encrypted for write
The Cloud IOT online documentation page "Device Security" describes a device provisioning process where a "Provisioner" creates a key pair, and distributes the private key to the Device. They go a step further and recommend using a revolving key strategy for added security. All steps in this device creation process can be automated using IOT core API's, with the exception of the key distribution step.
This alludes to there being a way to safely create the key pair, and transmit the private key to the device programatically for thousands of new devices rather than by hand for each device. Similarly there must be a way to generate and transmit new key pairs in the revolving key strategy.
Any suggestions on how to do this? Perhaps there is a standard method that I am not aware of. Thanks in advance for any feedback.
This alludes to there being a way to safely create the key pair, and
transmit the private key to the device programatically for thousands
of new devices rather than by hand for each device.
I believe the language here is deliberately less specific to allow room for cases when a device builder has a secure or unique way (e.g. encrypted radio) of transmitting keys to devices. In many cases, you will have a hardware-specific or OS-specific solution for updating device firmware and this mechanism is the best approach and allows you to revoke and recover compromised devices.
I think there are really two core buckets of approaches to distribution of the private key to a given device:
Distribution / initialization at manufacture / late-manufacture stage (secure)
Distribution post-manufacture (e.g. after device has been purchased / installed / deployed)
For distribution at manufacture or late manufacture, you generally are going to be installing the keys to the device using something that is physically connected to the device in a secure environment. At manufacture, I would imagine at the manufacture facility the (contract) manufacturer calls the API using delegated credentials to send Google the public key and then securely installs the private key on device. At late manufacture, the same registration process and secure installation of the private key occurs, it's just done outside of the manufacture facility by the person contracting to manufacture the device.
In both cases of device registration at manufacture, you can register multiple certificates per-device so that you can "change your password" effectively over time by rotating through the certificates associated to the device by expiring certificates or can revoke suspicious certificates, using additional on-device credentials. In some circumstances, this is good because if only one of the on-device credentials leaks, you can switch to an on-device, secured-at-manufacture alternate. There is a minor trade-off to this approach in that if multiple credentials for a given device can leak, you will have the banal risk of having multiple credentials leak at once. And this leads us to the second bucket of key distribution, post-manufacture.
For distribution of the private key after manufacture, it gets a bit more complicated because you're effectively creating another channel for devices to be managed in your registry. For this reason, it's difficult to advise on what to do should you not have an established secure channel for completely recovering a compromised device remotely.
Eddystone-EID beacons transmit Ephemeral Identifiers which will be resolved by Google's Proximity Beacon API. This means one can not detect an Eddystone-EID beacon without an active internet connection. The approach is pretty new, so there is not much info on the internet.
Generation of ephemeral identifier and resolving mechanism is described in this paper provided by Google researchers. Here is the summary of the procedure: Eddystone-EID beacons encrypt the value from their embedded time counters with AES-128 using their key, while the key is unique identifier for each beacon. The result is the ephemeral id that's goning to be transmitted. Like every 512 secs, beacons recomputes their ephemeral ids. When an ephemeral id received by the receiver side, the resolver tries to find the key which provides correct decryption among known predefined keys. The found key corresponds to identification of the beacon.
I'm wondering whether it's possible to implement an offline resolving/decryption procedure according to given paper, that works with Eddystone-EIDs on the market. Instead of using a global resolver at the cloud, can we develop a local resolver which works with much less number of beacons?
If yes, is there any previous attempts or implementations etc?
What's your opinions on this topic?
Yes, it is theoretically possible to implement an EID resolver in Android or iOS code that does the calculations to see if an EID transmission comes from a known beacon transmitter.
The mobile device implementation would need to use compatible AES-128 encryption libraries and somehow store copies of the keys needed to do the resolution for each beacon.
When building a server-side resolver implementation for testing purposes, I considered building such a library. I also learned it is very tricky to get everything exactly right. Many AES libraries only provide partial functionality so are unusable.
It is also important to note that US export restrictions on encryption software will make putting apps that do this in the Apple AppStore and Google Play Store problematic.
This is in context of an application in cloud communicating to internal application through vpn over https connection. (Both the applications are of same organization)
So, even when using the above things, is it required add an additional layer of security by encrypting the credit card information so that the other application needs to decrypt it using predefined key?
If you are dealing with credit card numbers then you really need to follow PCIDSS. 4.1 states that when sending cardholder information over open or public networks it must be "appropriately" encrypted. It only states HTTPS (so SSL/TLS must be enabled).
I appreciate that you are not limiting your question to only credit card information.
I would say that for most things HTTPS is absolutely fine. I have had to encrypt a second user's password before (to validate information on a form that the first user entered, a bit like a signature) but that is not related to what you are talking about using HTTPS and encryption with.
Your question might be worth posting over at security.stackexchange
Can someone point me to a doc or site with information about how to build the encrypted section(s) of a zigbee packet? I'm looking at the output of a zigbee sensor system and I can see where most of the 'data' packets are being produced but there is a section call NWK Payload that is encrypted. I've watched the whole sequence of the connection with the 'base station' and I don't see where any sort of encryption key is being passed.
This shows the section I'm referring to. The packet analyzer has figured out the rest.
Long term goal is to build these packets and use the sensors separately from the 'base station'. To do that I need to be able to replicate the whole communication cycle.
In Zigbee there is are two keys used for encryption: the Link Key and the Network Key. The Link Key is used during the network association process, and the Network Key is used to encrypt all traffic once the device is "associated" (also referred to as "joined") to the network.
If the device is HA (Home Automation), the security handshake goes something like:
Joining Device sends Association Request to the Trust Center (usually address 0x000)
Trust Center responds to joining device with a NWK Key packet. The contents of this packet are encrypted using the well know Home Automation Link Key.
You should be able to decrypt the NWK Key packet if you know the Link Key. I'm pretty sure I can't post the key (sorry), but you can probably find it online.
As for the actual encryption algorithm, that's defined in the main Zigbee Specification, which I believe you have to be a member to gain access too. There are a few open source Zigbee stacks though ZBoss and FreakZ.
You might also look at Wireshark, I believe they have a decent Zigbee packet decoder though I haven't used it personally.
We use here the Perytons sniffer (http://www.perytons.com).
They have an Add-On with which you can create, edit and transmit messages (in parallel of doing the capture). We also use the add-on for "constructing" the ZigBee packets and encrypt it based on what you need so you can consider using it for debugging your encryption process.
They have a 30 days free evaluation with some of the TG Add-On options enabled ;-).
Hope this helps.