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?
Related
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 ).
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 think this question is related to cryptography.
Say Player A and B want to play Rock Paper Scissor game through the Internet.
There is not a server that both play trust, and they do not trust each other not to cheat.
I want to know how can they play a fair game with given scenario.
To be more precise, if neither player cheated, there should be a mechanism to let both player ensure that neither cheated.
Here is a naive solution that does not work:
First, both players send their choices to a server. After server receive both choices, it sends out the choices to both player.
The reason why this won't work is that the server might be an accomplice of player A. It will secretly send player B's choice before receiving player A's choice. Then player A can make a choice that wins player B. Throughout this process, Player B has not way of knowing whether player A cheated.
You could use a secure hashing function and random number generators to make players commit to their move before revealing it.
Something like this:
Each player generates a random string, and sends it to the other player.
Each player generates a second random string, and keeps it secret (temporarily).
Each player chooses their move, and generates a signature for it, using the hashing function, and concatenating the two random strings to create a secret. Perhaps HMAC_SHA512( my_string + other_string, move ) in pseudo-code, where first param is the MAC's secret, and by + I mean string concatenation. Equally HMAC_SHA512( my_string, other_string + move ) works.
Players publish their signatures to each other. At this stage, they have made a public commitment to make a move with a matching signature.
Players then reveal their moves and second secret strings to each other, allowing the signatures to be verified.
This relies on the fact that if would be very hard to find a hash collision (two secrets which when combined with the other players "salt" and the move that would create the same signature). Technically, the hash function needs to have collision resistance and second preimage resistance to work well in this scenario - the former often implies the latter, and most HMAC functions available in a modern crypto library have these properties, at least from a practical standpoint of no known attacks better than brute-force. Once committed to a move signed with HMAC-SHA512 using a combined secret (combining the secret with data from the other player means you must look during the game, not search in advance for a collision), the players would find it impossible to declare anything other than the original signed move without being noticed.
It is also important that the generated random strings cannot be guessed, or all possibilities tried. They should be long (say 32+ bytes) and generated using a secure random number generator. If a player can simply try all the possible random strings, they could figure out what was being signed and respond with the correct counter-move.
Note that this method does not rely on a server. The server, or network, could create a man-in-the-middle attack here (by discarding one or both players' communication, and replacing with its own - it would not necessarily control the game result, but might mean the players were not really playing each other, but the server), so it is better if the communication is done securely peer-to-peer. If peer-to-peer is costly, then the only thing that has to be sent this way is the signature - if any component in-between the players then tries to change anything it would show up as the signatures not matching to published values.
I know that in iOS 7, the app's receipt and the In-App Purchase receipts are combined into an encrypted format with a structure shown here, automatically written to storage.
I know receipt(s) have fields, as documented here.
I know how to retrieve the receipt combo by calling appStoreReceiptURL.
I know how to validate that receipt by passing it to Apple servers either directly or via my own server.
But how do I parse the receipt to extract its fields?
I need some kind of identifier for each of the possible In-App Purchases so as to record the user's ownership in a way that I can verify repeatedly later.
If you send the receipt to Apple for validation, you will get back a JSON structure with all the receipt fields. Are you asking how to parse this JSON structure?
Check the issue: A complete solution to LOCALLY validate an in-app receipts and bundle receipts on iOS 7
In one of the provided answer author described the solution how to unseal PKCS7 container by means of OpenSSL and read all the contained fields. But using OpenSSL is only a one way how to read the receipt data. I also know another tool - CargoBay that operates with PKCS7 by means of native iOS methods without any 3-d party libs. I'd recommend also to check this question : iOS Restore in App purchases with receipts
My question is:
For the same card, each time the user (owner) use it, I'll use balanced JS to tokenize it and get a different URI. Then I'll add this card to this customer on Balanced. This will cause a customer has lots of cards although they are the same one.
So what's the suggested way to implement this? Assume that I will let user types his card each time he uses it.
More background on our project:
I integrate balanced payment with my website in this way:
Front end JS will tokenize a card and pass the card URI to our backend.
Backend uses python to assign this card uri to a customer and debit at some point.
Why not use the same card each time? It's a bit of a hassle for the user to have to enter their card info for every purchase, I think.
If you really must have the user re-enter the same card info multiple times, but don't want duplicate card resources sitting around, you can check the hash attribute of the card object that was just created. If it matches the hash of an existing card, don't associate the card to the customer, but instead use the previously-existing one.
https://docs.balancedpayments.com/current/api.html?language=bash#tokenize-a-card
You could use an if statement in the jquery on the page where you collect the card. If the customer has selected an existing card then the balanced.js code does not execute.
If the customer adds a new card then it is tokenized and we use the following function (in php) to add the card to the existing customer:
function add_card($customer_id = NULL, $card_token = NULL){
$customer = \Balanced\Customer::get($customer_id);
$customer->addCard($card_token);
}