In an EMV chip card with two AIDs, it is correct to use different IMK-AC keys for each AID or the same IMK-AC key for both AIDs?
I'm asking this question because we are having problems validating the ARQC for an EMV chip card. The ARQC validation is success only when the card is using one AID, and the ARQC validation is failing when the card is using the other AID. We have tested this several times and have the same result. My theory is the IMK-AC used to issue the AIDs are different, but I don't know if that makes sense?
Is there any way to know the IMK-AC KCV in an AID EMV chip card?
Also, In the TVR (terminal verification result) for the transactions are:
ARQC Success: 8000048000 (Online PIN entered ON)
ARQC Failing: 8000008000 (Online PIN entered OFF)
I don't know if the TVR could affect in any way the ARQC validation?
I'll appreciate any help on this issue.
Thanks!
Two different applications and hence two different card numbers, correct ?
While you personalize, IMK AC will not be sent to card, it is a key derived from the IMK-AC, diversified with pan and card sequence number, called Unique derivation key sent to the card, and hence both cards will have two UDKs even though the IMK-AC is same.
Since AID is different, ensure the ARPC verification is appropriate for the Cryptogram Verification Number. You can get this from 9F10(Issuer Application Data).
The value in TVR do not matter for ARQC validation, but what received from the terminal should be used for verification since it was used for generation by the chip.
You can add some logs from terminal, host and HSM here ( after masking sensitive data if performed using a live card ).
Related
I would like to know the X509Certificate2s that are on a smart card, where there could be multiple smart card readers with multiple cards and the cards have multiple certificates on them.
Using SmartCardReader Class I use FindAllCardsAsync to get all smart cards.
Is it possible then to get the certificates on that smart card?
Is there any property I can get from Windows.Devices.SmartCards which I can then use with the x509Store?
I have also tried to query the x509Store for certificates to find out if they come from a hardware device. With the help of this X509Certificate2: determine if certificate private key belongs to an hardware device, and if it needs a PIN I am able to get all certificates and to know if they are connected to a card reader.
The problem is that when a card is inserted into the card reader the certificates are added to the store, however, they remain there when you remove the card. The are only removed if you removed the card reader. The question casts the Private Key to a RSACryptoServiceProvider with the following code, however, this automatically shows a dialog to insert a card.
Dim rsaKey As RSACryptoServiceProvider = CType(x509.PrivateKey, RSACryptoServiceProvider)
If rsaKey.CspKeyContainerInfo.HardwareDevice Then
Debug.Print("Certifacte on Card")
End If
Using the x509 store and a X509Certificate2Collection is there another way to work out whether a certificate comes from a smart card and that card is still in the card reader?
By the way the question also has a suggested answer titled My preferred solution which does confirm whether the certificates in the store are software or hardware based, but this does not confirm whether the card is still inserted or not.
Is there any way to use a X509Certificate2 handle to find out the card it comes from, if any and then relate this to a similar property of Windows.Devices.SmartCard?
Given an application where users identify themselves by some id with an accompanying PIN code, how should PIN codes be saved?
The PIN codes are fixed length (6) and comprised entirely of digits. Once an account is selected, this pin code will be entered into pos terminals for authentication.
It is best of course, not to save the pin codes in the database as raw text. However, even good password storage techniques (ex bcrypt) seems to fall short. Due to the nature of pins, it is trivial to simply try all possibilities. (Ex try 000000-999999 on a given bcrypt hash). Is there a better way of saving PINs then?
I am building a device with GSM Modem and a SIM card. I would like to protect the SIM card with a pin to prevent its misuse when the devices are installed on field.
Storing the pin for associated SIM into each device would be cumbersome. Also, if SIM is replaced, I want the device to automatically know the PIN for the new SIM. So I was thinking of using a one way hash function to generate the pin from one or more properties of the SIM like its IMSI, ICCID, SIM Card Group Identifier, Service Provider Name etc.
When a SIM is inserted, the device can dynamically calculate the correct PIN based on these properties.
(I know that security based on secret algorithm violates the basic principles of computer security, but in this case I don't need it to be fool proof - I just need something better than leaving it unprotected.)
The problem is that none of these properties can be read before entering the PIN.
Is there any other property that can be read without entering the PIN? Or do you have any work around that does not require storing of PIN on the device in advance?
Yes, it should be possible to generate the PIN using the SIM properties itself (assuming you have relation with the card vendor and the operator).
PIN = some_function(sim_properties)
Regarding each properties that you mentioned:
ICCID - yes, this unique per card. No read restriction and cannot be updated. First choice to use.
IMSI - unique per card but cannot be used. You need to provide PIN to read this file.
SPN - yes, can be used as well, but is not unique per card. If you want to use this file, ensure that it will not be updated by operator via OTA (Over The Air) RFM (Remote File Management).
GID - this file is optional, better not to use it.
For the function itself, I propose using cryptographic hash instead only hash, to give more security.
Additionally, you may also ask the card vendor to add additional proprietary file (EF), which you can put additional data inside (additional keys, bitmasks, key index of master keys to be used, etc).
At the final step, do not forget to convert the cryptographic hash result into numeric format 4-8 digits.
I'm thinking through how to develop a validation on my Rails app that essentially checks to make sure that the credit card used for any given transaction by any user is unique in our system, such that all credit card may be used to purchase an item only once across the entire application for all users, for all time.
The thinking behind this restriction is that this app will sometimes run time-sensitive promotional deals, and we want to do our best to institute a "one purchase per credit card" system for these deals.
I was thinking of hashing the credit card number and just storing that hash in the db, then cross-referencing it at the time of each new purchase (so my payment gateway keeps the actual number, and I just keep a hash in the DB), but on further research, this seems like a bad idea.
So I'm back to the drawing board and looking for new ideas. Anyone know a good approach to this problem, while keeping as PCI-compliant as I can be?
I'm developing with Rails 3 and using ActiveMerchant to integrate with my payment gateway, Authorize.net, if that helps at all.
Certainly some hashing is a bad idea - either because it's low security, has some intercepts, or so commonly used there's rainbow tables. That doesn't mean all hashing is a bad idea - the only way to cross reference is going to be some way of uniquely and predictably identifying the information. Unless PCI specifically prohibits it - hashing is still the way to go.
Salt
Make sure you salt your hash - this prevents rainbow attacks, or at least requires the rainbow-attacker build a table with your salt in mind. In particular if you can keep the salt reasonably secure {I say only reasonably because in order to generate you need to have the salt which means it'll be in code somewhere}.
Choose a Good Algorithm
While MD5 is now infamous, and implemented in all kinds of languages, it's also so common that you can find pre-made rainbow tables. It's also extremely quick to generate a hash. Your system can probably tolerate a small amount of delay, and use a much more processor-intensive hash. This makes the cost of generating a rainbow table much more expensive. Check out the Tiger algorithm for example.
Hash more than once
If you have multiple related data points, multiple hashes are going to make it way harder to do a rainbow attack. For example: Hash(Hash(Card#+salt1)+expireDate+salt2) - requires knowledge of both the card # and the date to generate (easy for you) but can't easily be reverse-engineered (rainbow requires for every card # * every useful expire date + knowledge of both salts).
Edit: (your comments)
Reasonably secure: Only transmit it over an encrypted connection (SFTP, SSH), don't store it unencrypted - including live/iterative and backup copies, keep the file with the salt outside of the web tree (cannot be directly accessed/accidentally released), make sure permissions on the file are as restrictive as possible (don't allow group/global file access).
Dynamic salt throwing a random value into the hash is great for reducing rainbow attacks - you store that random piece in the table with the hashed value - now when building a rainbow you have to build one for every dynamic salt. However for your needs you can't do this - you need to know the right random salt to use the second time you create the hash (otherwise you'll never get an intercept on the second card use)... for that to be predictable/repeatable you'd then have to base the dynamic salt on some part of the number... which is effectively what multiple hashing with another data point does. The more data points you have the more you can hash in this direction - if you have the CVV for example (3 hashes), or perhaps you hash 8 digits at a time (for a total of 3 hashes: hash(hash(hash(1..8+salt1)+9..16+salt2)+expDate+salt3)).
Best Hash it's a moving target, but there's a good discussion on security.stackexchange. Which points to SHA-512.
faking your true credit card number online is the best way to prevent this from happening. Citibank clients can login and make use of this tool provided with all accounts. Just generate a number and exp date for use online, and all is fine , for now.
I think you are looking in the wrong direction. I would just check last 4 of card, ip and shipping addresses. The risks of storing that data versus the damage if a small number of users gamed the last 4 & ip solution is not worth it. (He says not knowing the nature of the purchases.)
Since address isn't collected...First 4, Last 4 and 4 Digit Expiration (all hashed of course) should provide the uniqueness you need to ensure that card was only used once.
If you want a "one purchase per user" system then why don't you just check the user's purchase history whenever they try to buy a special-purchase item to ensure that they haven't bought it previously?
user could register for multiple accounts.
although by checking users history, as well as enforcing 1 item per address for each purchase- you will likely be fine- you could also limit things by users name/ birthday/ whatever other identifying information.
Credit Card information can also change by the way- its actually very easy to purchase 100 gift credit cards with unique numbers so if you want to police things down to the most minute level... I dont think you will be able to just by cc numbers
Could anyone explain to me in simple programmatic terms how these RSA key dongles work? I know Blizzard has them for WoW and paypal as well as some of the trading sites.
Thanks!
The fob has a clock and a serial number that is used as a seed for a PRNG. When you hit the "show me a code" button, the fob displays a number that is the product of that timestamp and the serial number run through the PRNG. The server knows your fob's serial number and time, and does the same operation. If your codes match, you're authenticated.
You can calculate the previous/next N values on the server end to account for clock skew.
Programmatic terms aren't necessary. Just imagine two pieces of hardware (your dongle and something at the company) that generate the same numbers at the same regularly scheduled intervals. It would be virtually impossible to guess what the number is due to some proprietary algorithms, so if the number you type in (or is automatically sent by the dongle) matches the number at the server, your identity is validated.
At least with the dongle I have, you also have to supply a pin known only by you and the server. So, in order to be authenticated you need both something physical and something in your head. That combination is pretty hard to fake. Even if someone gets the dongle, unless they know your pin it's worthless. And if they know your pin, that information is worthless without the dongle.
Security Now! episode 103 talks about how they work. (That link is to the show notes, but there's a link at the top of the page to the audio podcast.)
Basically, the key fob is synchronized with a server and they're both seeded to generate the same sequence of pseudo-random numbers. The server knows it's you if you input the right number at the right time.