I am trying to understand the usage of SCP DEK in store data command.
As per GP Card spec 2.2.1- "The data encryption key (DEK) for decrypting sensitive data, e.g. secret or private keys. This key is a double length DES key and is used as a static key."
I requirement to encrypt the Store data APDU data. Now I have 3 questions
Is indeed SCP DEK used to encrypt EMV AUKs (Application Unique Keys) present in one of these store data commands?
If statement #1 is correct the which key is used to encrypt data field in the APDU?
Is the an indicator in commands prior to store data which says that data field in store data command would be Encrypted or NOT?
I would be able to set store data CLA, INS, P1 and P2 as per GP card 2.2.1 and Amendment D spec.
Asking this question here since crypto.stackexchange does not have global platform and cryptography tags
Any help is appreciated
Nevermind, I found answer
Yes
S-ENC Secure Channel Protocol '03' – Public Release v1.1.1
section 6.2.6 APDU Command C-MAC and C-DECRYPTION Generation and
Verification
External Authenticate command P1 as per 7.1.2.1 Reference Control Parameter P1 – Security Level - (Encrypted value =03 - C-DECRYPTION and C-MAC/ Clear value = 01 - C-MAC)
Related
I have successfully generated a ARQC by satisfying the PDOL required by the ICC. The ARQC required the following PDOL tags.
9F66 TTQ
9F02 Amount Authorised
5F2A Transaction Currency Code
9A Transaction Date
9F37 Unpredictable Number
The AID returned from ICC
06 01 11 03 A00000 0F83000000000000000000006975A844
The Cryptogram Version Number as above 17 (11 Hex)
My question, when I submit the transaction to the acquiring bank for authorisation via a ISO8583 host to host connection, in the ICC related data element do I only populate the EMV tags required by the PDOL and response Tags, or do I submit all ICC tags including for example the 'Terminal Verification Results' which was not required as per PDOL ?
Based on the CVN 17 the required fields to validate Cryptogram is
9F02 Amount
9F37 Unpredictable Number
9F36 ATC
9F10 CVR
Agree with comment from Michal.
Acquirer require much more EMV tags to transfer them to Card Issuer side and identify correct card profile and finally validate Cryptogram. The list of EMV data can be different in small details and place of these EMV Values transferred in ISO 8583 message. Refer to your Acquirer ISO 8583 specification.
The short summary of EMV tags and other fields required by Acquirer Interface you may see in EMV specification Book 4, Article "Authorisation Request".
Keep in mind that contactless cards, like your Visa PayWave may need to transfer own specific Tags depending of Card Brand Specification.
Unfortunately this is a question you should ask to your acquirer. The usual is that you populate all the data you have, especially because some of them may be used for risk management rather than cryptogram calculation. List of mandatory data elements is usually longer than what is required purely for cryptogram generation. Second thing is that your application should not interpret proprietary data elements like Issuer Application Data unless you are required (remember there are other card application specifications and you might have trouble differentiating them on the acceptance side). Side note - AID is not IAD, 9F10 is not CVR.
In most simple terms, what your card is doing here is generating a cryptogram based on elements in CDOL (elements, its order and size, will be mentioned in payment scheme docs for each CVN). So at the issuer end it should get the same elements to validate the cryptogram( and optionally to generate the response cryptogram ).
I have only an OpenPGP key's public fingerprint. I do not know the key ID or almost anything else.
How can I get the corresponding public key? Are there any online service to do this?
How the Fingerprint and Long and Short Key IDs are Related
Each OpenPGP key has a fingerprint attached, calculated mainly from its public key packet which also contains the creation time. The calculation is defined in RFC 4880, OpenPGP, 12.2. Key IDs and Fingerprints.
There are short and long key IDs, which resemble the lower 32 respective 64 bits of the fingerprint. For example, looking at the IDs of my OpenPGP key:
fingerprint: 0D69 E11F 12BD BA07 7B37 26AB 4E1F 799A A4FF 2279
long id: 4E1F 799A A4FF 2279
short id: A4FF 2279
Fingerprints and key IDs are used, as sharing and comparing a whole key with usually 1024 to 8096 bits (adding some more for headers like the creation date) is very impractical.
Receiving Keys from Key Servers
There is a bunch of key servers used to distribute keys -- they communicate with each other, choose any of them. GnuPG's option --keyserver hkp://pool.sks-keyservers.net (often set in it's configuration file ~/.gnupg/gpg.conf for Linux/UNIX systems, another path on Windows) uses a pool that will chose a random one each time you use it.
You can use any of those short and long IDs respective the full fingerprint to fetch the key using the --recv-keys command in GnuPG, while the fingerprint is the most specific (and chances for collisions with short key IDs are highest).
If no colliding keys exist, following statements would fetch the same key:
gpg --recv-keys 0D69E11F12BDBA077B3726AB4E1F799AA4FF2279
gpg --recv-keys 4E1F799AA4FF2279
gpg --recv-keys A4FF2279
If you want to query the key servers from your browser, make sure to search for the fingerprint, long or short key ID prefixed by 0x to indicate a search for key IDs (the GnuPG command line interface will do this for you automatically).
Yes, there are servers for this. You can get key like this:
gpg --recv-keys <KEY_ID>
Update: see how KEY_ID interconnected with fingerprint:
Fingerprint: EC2392F2EDE74488680DA3CF5F2B4756ED873D23
Long Key ID: 5F2B4756ED873D23
Short Key ID: ED873D23
I am using revel to build my webapplication and trying to write authentication module.
I finished with sign up part and now heading to write sign in part.
I read about security part on The definitive guide to form-based website authentication and will use this recommendation.
What I am really do not know is, how sign in works. I am imaging that the process works like this:
User write username and password into the html form and press sign in
Server receive request and the controller will check, if user information match with data on database.
If yes, how continue.
The third point is where I am staying. But I have some idea how could works and not sure, if is the right way.
So when sign in information match with the database, I would set in session object(hash datatype) key value pair signed_in: true. Everytime when the user make a request to the webapplication, that need to be authenticated, I would look in the session object, if signed_in is true or not.
This is the way I would do, but as I mentioned above, I do not know if it is the right way.
Yes like #twotwotwo mentioned, give it the user id and also a role.
So server side rendered flow: Step 1
user sends username (or other identifier) and secret.
using scrypt or bcrypt the secret is checked against the stored salted hash in the database
if it matches you create a struct or a map
serialize struct or map into string (json, msgpack, gob)
encrypt the string with AES https://github.com/gomango/utility/blob/master/crypto.go (for instance). Set a global AES key.
create a unique cookie (or session) identifier (key)
store identifier and raw struct or map in database
send encrypted cookie out (id = encrypted_struct_or_map aka the encrypted string)
On a protected resource (or page): Step 2
read identifier from cookie
check if id exists in db
decode cookie value using AES key
compare values from cookie with stored values
if user.role == "allowed_to_access_this_resource" render page
otherwise http.ResponseWriter.WriteHeader(403) or redirect to login page
Now if you wanted you could also have an application-wide rsa key and before encrypting the cookie value sign the string with the rsa private key (in Step 1). In Step 2 decode with AES key, check if signature valid, then compare content to db stored content.
On any changes you have to update the cookie values (struct/map) and the info in the database.
I'm writing an iPad game that sends hi-score type data (ie data beyond what Game Center supports) to a Google appengine datastore. It sends these updates via http GET or POST requests, such as http://myapp.appspot.com/game/hiscore/925818
Here is how I thought to ensure the appengine datastore isn't spammed with false data.
zip/encrypt the payload data using hardcoded p#ssw0rd saved in the iOS binary. Encode that binary data as base64. Pass base64 payload in the url query string or in the POST data. At handler, unbase64, then unzip data with p#ssw0rd. Follow instructions in payload to update highscore-type data.
CON: If p#ssw0rd is somehow derived from the iOS binary, this scheme can be defeated.
Is this adequate/sufficient? Is there another way to do this?
There is absolutely no way to make sure it's your client that sends the data. All you can try is to obfuscate some thing to make it harder for spammers to submit data.
However I think there are two thing you can do:
Have some kind of secrect key saved in the binary
Have a custom algorithm calculating some checksum
Maybe you can go with a combination of both. Let me give you an example:
Create some custom (complex!) alorithm like (simplyfied):
var result = ((score XOR score / 5) XOR score * 8) BITSHIFT_BY 3
Then use your static stored key with that result and a well known hash function like:
var hash = SHA256(StaticKey + result)
Then send that hash with the score to the server. The server has to "validate" the hash by performing the exact same steps (evaluate algorithm + do the SHA256 stuff) and compare the hashes. If they match the score hopefully comes from your app otherwise throw it away, it comes from a spammer.
However this is only one thing you can do. Have a look at the link from mfanto, there are many other ideas that you can look at.
Be sure to not tell anybody about how you're doing it since this is security through obscurity.
Ok me, there are 2 methods to do this.
1) Purchase an SSL certificate for $FREE.99 and open HTTPS connections only to your server to submit hiscore type data. Connection speed should be around 500 ms due to handshake roundtrip time.
2) Embed an RSA public key certificate in your iOS app, and have the RSA private key on your server.
You can then do 1 of 2 things with this second scheme:
IF your data messages are really small (≤256 B) you can just encrypt and send 256B packages (RSA payload is limited by the number of bits in the key)
ELSE IF the data is too large (>256B), generate a random symmetric key (AES), and pack:
SYMMETRIC AES KEY ENCRYPTED WITH RSA PUBLIC KEY
BINARY DATA ENCODED WITH SYMMETRIC AES KEY
The server then takes the first 256 bytes and decodes it, then the server uses that AES key to decrypt the rest of the message.
The above 2 only prevent eavesdropping, but it means the data format of your messages is hidden. At some level, it is still a type of security by obscurity, since if the hacker has your public key AND your message format, they can manufacture messages.
Looked on google and couldn't find anything.
Any good resources to get started designing my backend for a RESTless webapp thats going to rely heavily on API keys.
I know how to write restless webservices etc, just never used API-keys. Generally do people just generate guids for users etc?
Here's how I'm creating API keys for a web service:
string CreateApiKey(int length)
{
var bytes = new byte[length * 2];
using (var rng = new RNGCryptoServiceProvider())
rng.GetBytes(bytes);
var chars = Convert.ToBase64String(bytes)
.Where(char.IsLetterOrDigit)
.Take(length)
.ToArray();
var key = new String(chars);
return key;
}
GUID's are typically not "random" enough and can be easily guessed by the bad-guys.
Take some "random" data like the user's password hash, some random numbers and run the result through sha1 or a similar hash function.
If you want one API key per account, simply add it to the account metadata table. Otherwise use a table linked to the accountIds to store the api keys.
Server side use a cache using the api-key as the key to store temporarily the account metadata so you only need to go to the db once per session.
And of course everything must go over https to avoid that the API key be stolen.
Now if your service is "session" oriented you can consider using a temporary session key so you do not need to expose the API key. Look for public key encryption to investigate this further.