Can somebody please clarify how DDA protects EMV cards against cloning
From what I have learned so far a random unique number is generated by terminal and sent to card
Card will generate a Private/Public key and then sign the the card data with private key and send it to terminal for verification
How does this protect against cloning ?
Card will not generate private and public keys. Private and Public keys are encoded into the chip during personalization. First you need to understand what the terminal and card have in hand to understand this. Go through this answer.
Now that you know where each keys come from, during DDA, using the ICC private key, card will generate a certificate, and terminal will validate the certificate using ICC Public Key.
Detailed process is explained in EMV 4.3 Book 2 Security and Key Management, section 5 and 6. Download from here . Start reading from SDA and have the basis clear.
Related
I'm working on a project where two clients can send files to each other via web sockets (using Socket.IO). Each chunk is encrypted with AES.
Currently, the clients connect to the server, they each generate an RSA public/private key pair on their devices, they then announce their public keys to the server which sends them to the other client, and this gets stored by said client. Before data is sent, it is encrypted with AES using a random key and a random IV, and the AES key is then encrypted using the other client's public key. The data is sent across, the other client then decrypts the AES key using their RSA private key, and finally decrypts the content using the decrypted AES key and saves it to a file on their disk.
The issue is that the server could easily just replace one client's public key with its own, and steal the data. The only solution I can think of is for the clients to contact one another and manually verify their public keys... I'm not sure how I'd go about automating this process. Services that provide E2EE seem to generate a matching code on each device, but I'm having trouble finding any information about how this is actually implemented, like how would two devices generate matching codes without talking to a server or each other in between, and if they do, then the server knows the code anyway right?
I've considered using WebRTC to send the public key from one client to the other without having the data go through the server, but I'd appreciate alternative approaches. Thank you in advance! :)
To prevent MITM, users are supposed to "manually compare public key fingerprints through an outside channel", as explained in this article regarding the Signal Protocol.
Usually, it means checking an hexadecimal string over a trusted communication: face to face, phone, ... Depending on your requirements, you might also consider that an attacker cannot access both your tool and emails at the same time and consider emails your trusted communication.
I am working on a project which requires Secure Messaging of an EMV card to protect data sent to/received from EMV cards.
According to the EMV Book 3, section 6.3.2:
For my understanding, we can use 'Secure Messaging' on every command/response pair.
For example, we can use CLA='8C', INS='CA' for Secure Messaging Format 1, and CLA='84', INS='CA' for Secure Messaging Format 2
However, when I tried on two of my cards I got error 6E 00 -- Class not supported.
What's wrong with my understanding about the 'Secure Messaging'?
None of the current EMV protocols seem to support secure messaging. Consequently, your card/EMV applet won't support secure messaging either.
Also, I'm not quite sure what exactly you would want to use secure messaging for ... Excahnged information is already authenticated (under the assumption that you perform a transaction and that you do CDA/SDA/DDA). So you probably aim for encrypting the information exchanged between the terminal and the card (specifically things like the amount charged, static card data, etc.) However, I doubt that this would make much sense based on the design of the current EMV infrastructure:
Terminals are currently not assumed to be trusted (at least with regard to the EMV protocol exchange between the terminal and the card). Consequently, you won't be able to implement any form of mutual authentication between the terminal and the card. Only the terminal could authenticate the card, the card could authenticate information received from the issuer (e.g. issuer scripts), but the card could never authenticate the terminal. As a result, impersonation of the terminal side would be possible despite encryption. Hence, an attacker in the middle would still be able to read and decrypt messages.
From a comment by Michal Gluchowski:
Maybe to extend what Michael has said, where next generation EMV is planning to go is to introduce channel confidentiality to eliminate passive eavesdropping. It will, however be possible to impersonate terminals (only card certificates will be authenticated). Current EMV uses secure messaging only for issuer scripts as it requires symmetric secret key that is known to issuer only. From the transaction perspective all the data terminal exchanges are plaintext (and issuer scripts are simply passed through without terminal analyzing or modifying them).
Source regarding next generation EMV & channel security: Next Generation Kernel System Architecture Overview, EMV 2nd Generation, Version 1.0, Sept. 2014
I am trying to understand the key high level details behind verifying trust when downloading an archive.
This is my understanding of how it could be done:
On the Software Developer side:
Obtain a certificate from a public CA like verisign
Generate a hash of your archive and then encrypt this string using the private key from your certificate, this is the "signature"
Host the archive for download, along with a separate file which contains the public key from your certificate + the signature generated in step 2.
On the (user) client side:
Download and unpack the archive, download the signature + public key file
Decrypt the downloaded signature using the downloaded public key, save this value
Iterate through the public root certificates embedded within your operating system. For each root certificate, decrypt the signature value and compare the result to the result in step 5.
Once a match is found in 6, you have verified that the author's private key descends from the chain of trust of the CA which you found matched in step 6.
This all assumes that the software developer used a CA for which we have an embedded root certificate in our clients OS.
Questions:
Is the above method sound, or am I overlooking key details?
Given a blank slate client that you control, if I wanted to combine the public key + signature + archive into a single file that I could make the client understand and parse, are there any widely supported formats to leverage for organizing this data?
Aside from being a little too specific on Developer (2) (that describes how RSA signatures work, but ECDSA is perfectly well suited to this task) that sounds rather like Authenticode minus some EKU restrictions. This leads me to ask "why not use Authenticode signing?".
The structure I'd consider is the PKCS#7/CMS SignedData format. It can describe multiple signatures from multiple certificates (sign it ECDSA-brainpoolP320t1-SHA-3-512 for anyone who can read it as well as RSA-2048-SHA-2-256 for most of us, and DSA-1024-SHA-1 for anyone whose computer was built in 2001).
For data file you can just use SignedData normally, for executables it's harder since there are semantic portions (so you have to squirrel it away somewhere and use indirect signing).
If you do your signing with .NET, PKCS#7/CMS SignedData is available for both signing and verifying via System.Security.Cryptography.Pkcs.SignedCms (though you probably have to define your own chain trust rules outside of that class).
I need to be able to read card and company identification data from European digital tachograph company cards (smart cards). These are described within the document COMMISSION REGULATION (EC) No 1360/2002 but I have run into a problem. The data I need to be able to read is contained within the file EF Identification, which must be read with secure messaging and I therefore need to issue a Manage Secure Environment APDU command that requires a key identifier that identifies a key residing on the card.
I don't know where to find these key identifiers or the data that makes them up (described in an appendix of the document). I am waiting for feedback from our partners in Europe but thought I would take a chance an ask here in the hope that someone will have done this and be able to offer some advice.
The key identifier is made up of an equipment serial number, a date, a manufacturer code and a manufacturer specific type. This suggests a problem as I need to be able to access the data from any company card, regardless of manufacturer, issuer or holder. Not sure how I can get the data to compose the key.
I realise that this is pretty specialised information but have been stalled for over a week so am pretty desperate to find a solution so I can continue.
I believe that you first have to obtain a certificate from a country CA. You can then perform the following algorithm (simplified from Appendix 11, section 4):
Select and read the card certificate (EF_CERTIFICATE)
Issue a Manage Security Environment command to select the Root CA public key
Issue a Verify Certificate with the country CA certificate
Issue a Manage Security Environment command to select the country CA public key
Issue a Verify Certificate with your certificate
Issue a Manage Security Environment command to select your public key
Issue an Internal authenticate command. Verify response.
Issue a Get Challenge command
Issue an External authenticate command
Calculate the session key
Select File EF_IDENTIFICATION
Perform a Read Binary command using secure messaging (you need the session key to calculate the checksum and decrypt the result).
I don't know the standard, but I would assume that you read out EF Card_Certificate, recover the certificate content and extract the key identifier from that.
Assuming you have the root certificate (it is published here: http://dtc.jrc.it/erca_of_doc/EC_PK.zip), you will need to:
Read EF CA_Certificate
Follow the algorithm in Appendix 11, section 3.3.3
Extract the CA public key from the certificate content
Read EF Card_Certificate
Follow the algorithm in Appendix 11, section 3.3.3
The Key Identifier should now be byte 20-27 of the recovered certificate content.
Last summer, I was working on an application that tested the suitability of a prospective customer's computer for integrating our hardware. One of the notions suggested was to use the HTML report generated by the tool as justification for a refund in certain situations.
My immediate reaction was, "well we have to sign these reports to verify their authenticity." The solution I envisioned involved creating a signature for the report, then embedding it in a meta tag. Unfortunately, this scenario would require the application to sign the report, which means it would need a private key. Once the application is storing the private key, we're back at square one with no guarantee of authenticity.
My next idea was to phone home and have a server sign the report, but then the user needs an internet connection just to test hardware compatibility. Plus, the application would need to authenticate with the server, and an interested party could figure out what credentials it was using to do that.
So my question is this. Is there any way, outside of obfuscation, to verify that the application did indeed generate a given report?
As Eugene has rightly pointed that my initial answer was to authenticate the receiver. Let me propose an alternative approach for authenticating the sender
authenticate the sender:
When your application is deployed at your client end, you generate and deploy a self signed PFX certificate which holds the private key.
The details of your client and passphrase for the PFX is set by your client and may be you can get it printed and signed by your client in paper to hold them accountable for the keys which they have just generated..
Now you have a private key which can sign and when exporting the HTML report, you can export the certificate along with the report.
This is a low cost solution and is not as secure as having your private keys in a cryptotoken, as indicated by Eugene, in the previous post.
authenticate the receiver:
Have a RSA 2048 key pair at your receiving end. Export your public key to your senders.
When the sender has generated the report, let the report be encrypted by a symmetric key say AES 256. Let the symmetric key itself be encrypted/wrapped by your public key.
When you receive the encrypted report,use your private key to unwrap/decrypt the symmetric key and in turn decrypt the encrypted report with the symmetric key.
This way, you make sure that only the intended receiver alone can view the report.
I'd say that you need to re-evaluate possible risks and most likely you will find them to be not as important as you could think. The reason is that the report has value for you but less likely for a customer. So it's more or less a business task, not a programming one.
To answer your concrete question, there's no simple way to protect the private key used for signing from being stolen (if one really wants to). For more complex solutions employing a cryptotoken with private key stored inside would work, but cryptotoken is itself a hardware and in your scenario it would unnecessarily complicate the scheme.