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.
Related
I'm developing a solution which stores in a DB, for each customer, an RSA key which will be used to sign payments.
Those keys are so called SIM keys created via an SKS HSM, long story short we don't store actually the key in our DB but only an encrypted blob that only the HSM can use. In this way no one, except the HSM, knows what the keys are.
In order to prevent an inside attacker, with access to the DB, to switch keys among users it was decided to calculate, for each key, an integrity check and store it together with the key.
The solution is to perform an HMAC of customerId + key, in this way it would be impossible to switch keys among users without breaking the integrity check.
The key used to calculate the HMAC is dedicated for this use case and is stored in the HSM. However this point is the one I would like to change and for which I'm making this question.
Technically speaking it would be possible to calculate the integrity check using the RSA key itself by encrypting customerID + key using the public part of the key.
However CTOs are blocking this solution because they said the same key should never be used for signing and encrypting.
In my opinion the guideline to have separate keys for signing and encrypting doesn't apply to this case, in fact the guideline is true but only if we would actually expose an API that perform encryption and signing using the same key, which is not the case. The encryption operation we perform is against data generated by the application itself, not an input, is always the same for the entire lifetime of the key and is used only for the integrity check of the key itself.
I'm looking for someone with security knowledge that can help me understanding if the principle "don't use the same key for signing and encryption" really applies to this case, which in my opinion doesn't.
Thanks a lot.
Your CTO is correct on blocking this. Because you didn't give the details on what kind of payment solution you're building, just the fact you're storing, process and/or transmitting cardholder and/or sensitive authentication data puts you in scope for a PCI-DSS or a PA-DSS audit.
But there are very strict rules for key rotation, strength (you didn't mention the SHA to use with HMAC) and storage when handling sensitive cardholder data.
If you aren't familiar with the PCI Security Council, get ready to learn fast. They publish the guidelines that you as a developer must abide by if you are either developing an in-house solution or one for resale. The first overview are the guidelines themselves:
https://www.pcisecuritystandards.org/pci_security/maintaining_payment_security
As stated above, this forum really is no place to begin to discuss the details of all of the required secure coding practices, network segmentation considerations, employee separation of duties, etc. that are included in complianc = and along with mountains of paperwork and possible quarterly scans. And, based on your size and payment volume, an outside auditor.
In a former position I managed the US, Europe and South America's PCI & PA-DSS software compliance programs and it was very costly. Talk to an expert because you do not want to be the next breach of the day. It sounds like your CTO understands the implications so I'd listen to him.
I'm trying to compute digital signature RSASSA-PSS with sha256 for my IdentityIdentificationData (ASN1).
Directory file address 0x3D00
Aplication ID A000000061123A22738F4421
Private key folder 0x2F01
My ASN1 encoded hex data after sha256 encoded:
860c30a5f2b254ee92cbd3ec5c4282a940853aaef5f36d50ca20050637aaf4b0
I'm sending this command after SAM pin verified
MSE:SET
002241B606800191840110
SW1SW2:9000
Select File
00A40800043D002F0100
SW1SW2:9000
PSO: Compute Digital Signature
002A9E9A20860c30a5f2b254ee92cbd3ec5c4282a940853aaef5f36d50ca20050637aaf4b000
SW1SW2:6982
I'm a bit new on smart cards. How can i solve this problem. What is wrong or missing.
My SAM don't want to algorithm identifier for RSASSA-PSS.
6982 means: Security condition not satisfied
You should probably send the VERIFY PIN command directly before the PSO: Compute Digital Signature. Signature generation generally has very high requirements with regards to PIN, because the user has give consent for each and every signature. Hence the PIN may be invalidated by each command, especially if that command is an MSE:SET command. Selecting a DF by name may also influence the security environment.
So try the following order:
SELECT by Name (AID)
MSE:SET (for digital signature)
VERIFY PIN
PSO:COMPUTE DIGITAL SIGNATURE
The signature may also be depending on other security related objects such as an authentication key, for instance one used to setup secure messaging.
Can you check the access condition of RSA_Sign key ? If the access condition is NEVER then you wont be able to sign with this key. So in such case, SW 6982 make sense.
002241b606800191840181 mse:set is worked on me.
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've done a fair bit of reading about digital signatures but I can't for the life of me work out why I'd need to verify the signature of a digitally signed file uploaded on a mirror site.
The question popped up when I tried to install Maven:
https://maven.apache.org/download.cgi
The site urges you to "verify the signature of the release bundles against the public KEYS used by the Apache Maven developers".
I understand the need for integrity which a checksum provides (granted MD5 is considered weak) - why do I need to do more? I know the file that I've downloaded has not been modified since the checksum was initially generated.
Digital signatures are supposed to provide integrity, authenticity and non-repudiation.
1) Integrity is already provided anyway by confirming the checksum.
2) Authenticity - verifies identity of signer. In this case, the signer is the owner of the public key (supposedly a maven developer). In this scenario, do I really care who signed the file?
3) Non-repudiation - Do I really care that the developer can't deny the file was signed by him/her? Maybe if the maven developer created a malicious file and I wanted to sue them for distributing it...
I don't see the significance of authenticity here. I KNOW the sender (eg. someMirrorSite.com) is not the one who signed the file since if I use their public key to try verify the signature, it would be invalid. If I use the maven developer's public key all I'm verifying is the fact that the maven developer signed the file (granted they have a valid certificate which links that maven developer with their public key).
So basically the question is: Provided that I trust maven.apache.org, why should I verify the signature of the file hosted by the mirror site when I can just simply verify the checksum of the file?
Is basically a perspective, do I care who made or compiled a file? Who is behind this so called signed document/file/byte array?
Behind a signed file is Private Key Infrastructure, is like having a notarized document when a particular risky transaction is on play and a bunch of lawyers around, why should I care? Well it depends how important that activity is for you or a third party. Let's say You want to sell a company (small business). This is risky, may be not for you but for the third party, he will make sure there is a notary present to witness the transaction and the state he is receiving the company. At this point it becomes clear to you that you also need a notarized document of you selling the company. Who knows what's going to happen next? May be you don't care what happns next, as long as it's sold, so no notarized document (aka digitally signed document).
Check Integrity = Just lawyers
Digitally Signed Document = You don't trust lawyers that much so you need a notary (who is basically a lawyer anyway :-))
If there is a file F, and C = checksum(F), then when you download F you can recompute C and see if it matches the published value. But, how do you know if this published value of C can be trusted? If I am "Evil Inc." I can make a compromised copy of F, call it Fe and then compute its checksum Ce, and publish both on my website. Many people will not bother to even look at the checksum, but even those that do will be fooled, because they will compute Ce too.
Using a Public Key signature as the checksum is an attempt to strengthen this procedure.
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.