I tried google, but its not what I want. Google says, its a gathering to check how securely a signing key is stored based on distributed access to the key.
I have this class which has 3 Strings(broken key) and respective attributes (key check values, zone key check values, encryption master key). Using which I derive a Master key. I cannot put up the code here, as it violates my security policy. btw this is for smart cards.
If any one has any idea of this, please explain or point me to it.
OK, I'm going to be assuming a simple symmetric key (3DES or AES) split into 3 parts here. I can only answer because I make this assumption.
A key value is randomly generated, this is the key you're going to protect. Lets call this key the master key. A KCV (key check value) is calculated over the master key, so if it is regenerated the correctness of the key can be verified with relatively high certainty without revealing the value itself. The KCV doesn't leak information about the key material itself as the calculation of the KCV is one way.
This key is split into three parts using other random values and XOR. First two other random keys are generated. The third key is calculated to be the XOR of the other keys and the master key. KCV values are calculated and written down. The three keys can now be distributed to 3 different actors. These actors are called key managers in the role they perform in the ceremony. Commonly the key managers secure access to their key.
Now to regenerate the master key each key manager writes down their part of the key. The KCV of the key is verified before proceeding to make sure that no input errors have been mode, or that the value is not that of a different key. Now if you calculate the XOR of the three keys then you'll get the master key again. This value is again compared to the master key.
So that's all there is to it.
With regards to the security of this scheme:
you need all three keys as the other keys basically provide a One-Time-Pad encryption over the key value, which provides a very strong notion of security
the common KCV is a dangerous notion, as an encryption of an all zero block - the most common scheme - may leak sensitive information (e.g. for counter mode security with a zero nonce and counter). E.g. a HMAC over an empty value may be a better idea
obviously you need a secure random number generator to generate the keys or your scheme is likely to be insecure
it will be hard to generate the wrong key on purpose; commonly the KCV is three bytes, so the chance of one or two people colluding and generate the KCV of the master key is 1 in 2^24 (2^24 is over 16 million).
Key Ceremony in cryptography means that how you will activate your Signing key for different purpose like CA key when issuing a certificate. Key Ceremony have very strong security level that a key is activate with m of n rule, key is stored on secure physical location in Laptops or in HSM(hardware to store keys).
For more detail see WebTrust Principles and Criteria for Certification Authorities – v2.2 document ,download from http://www.webtrust.org/principles-and-criteria/docs/item83987.pdf, in section 4.4 CA Key Usage
On a high level, It's a process of rotating the cryptography keys on Production/UAT environment between two entities and then one entity send a request to another entity to make a session between them with the help of the keys. Keys can have certain roles to encrypt/decrypt the message, to check the integrity of the message e.t.c.
Related
I look out many password managers like keeper, 1password, secret-in and I am following secret-in password manager to create my own project and trying to add same features, but got stuck at storing the data of users like his/her secrets, payment secrets in encrypted form. I read encryption model of keeper here but still didn't understand. Where to store a server side encryption key?
I have some data that is symmetrically encrypted with a single key in my database. Rather than hard coding it into my code, I am looking for a safer way to store the encryption key. Where can I safely store it?
The approach here is quite simple.
You only send encrypted data to the server for storage/backup.
The encrypted data received doesn't come with a key.
You need to ensure all encryption and decryption occurs locally on the users device. Thus the user needs to supply the key.
Users aren't good at providing high quality key material, so instead, require the user to provide a password, take that password and pass it through a hash-based key derivation function with parameters that make the function slow (high ops, high mem requirements). An algorithm like pbkdf2 with a strong PRF like HMAC-SHA-2 should be sufficient.
Update:
To answer your specific questions, you need to perform the following steps, you will need to use a cryptographic library that supports key derivation from password and symmetric encryption, like libsodium.
request password from user on first use
run this password through key derivation to derive a key from it: https://libsodium.gitbook.io/doc/key_derivation
execute encryption of user data with key: https://libsodium.gitbook.io/doc/secret-key_cryptography
destroy the key and send data to server for backup
I have Mifare DESFire EV1 with 4Kb of memory. I have created an application with AID "000001". I want to authenticate with key number 1. However, I get "no such key" error code.
So probably I don't know the key inside the card, right? So how can I find out the keys? Should I contact the vendor?
"No such key" means that the key number specified is invalid.
DESFire keys are numbered from zero. Are you sure you created the application with the correct number of keys (i.e. at least two)?
To authenticate with the application master key, use key number 0.
The initial key value is defined by the card settings. The default value is written in the manual.
I have a question about when AES generate a key and IV how would the user know what the key is or how the program would know which key to use like it is generated. For example like if there is a encryption method that encrypt the file and generate the key and IV. When the program restarts or be used another day they would want to use the decryption but how would you know or the program knows thats the key for that file.
I understand the decryption and encryption by looking at it. I just dont know where the information is store to retrieve the key?
Key management is a large part of any cryptography related protocol. It takes a book or so to explain.
One of the most known methods is using a password (see password based encryption in PKCS#5, where a key is generated from a (stored) salt, number of iterations and of course the password (encoded to bytes). Another option is to store the key on some removable device like an USB key.
Usually the main key is not used to encrypt the data, but an intermediate key called the data or session key is used. For instance PGP encryption generates a data key and encrypts it with a public key of an asymmetric key pair.
Then there are smart cards, TPM modules, HSM's, key containers (possibly provided by the OS), key sharing protocols etc. etc. etc..
So ... it depends.
Sometimes it is easier to think of a key as another secret. By encrypting something you've only "compressed" your larger secret (your plaintext) into a smaller secret (the key) that you have to keep and manage. This secret however may have been generated in advance, or may have been generated by other means. If you just generate your key at the same time and location as your ciphertext, you haven't solved anything yet, you only made your secret smaller.
It's easier for the IV, the IV can simply be stored with (commonly, in front of) the ciphertext.
The RSA algorithm is used for encryption (plain text to cipher text) and decryption (cipher text to plain text) of data. What is the need for using public keys in these sites; why is data encrypted as everything is viewed by everyone?
Why do we need to use public key cryptography in Google; how does it provide security?
What is the need for using public keys in these sites?
It is required to set up a shared secret (a big random number) that is used for further symmetric crypto. Public-private key crypto allows one to share a secret message (symmetric key material) even when each and every message is monitored and eavesdropped. See Hot does SSL works? for more info.
The problem with public-private key crypto is that it is dead slow, whereas symmetric crypto is dead fast. The benefit is that public-private key crypto uses two keys for encryption and decryption and this is what allows to securely share a secret through the insecure channel, whereas symmetric crypto uses a shared key for both operations and you need both parties to have the same shared key.
Why is data is encrypted as everything is viewed by everyone?
When data is encrypted all that an observer can see is pure random noise. An observer cannot understand anything from the encrypted communication. Unless storing encrypted communication, like NSA does, and later asking Google and other companies for their private key. In this way they can decrypt old communication.
Why do we need to use public key cryptography in Google; how does it provide security?
Many agencies would like to know what people search for: "how to make a bomb", political disputes, etc. Advertisers would like to know what people interested in so that they can bring relevant ads. If something is provided to you for free, you are the product. You sell your information (your interests) and when this is done on a global scale suddenly huge money become involved.
Public-private key crypto in this sense provides privacy. Only you and the server can understand the traffic, but no one else: no intermediate hubs, your ISP or government body.
Before Facebook switched to SSL-by-default, all traffic was indeed plain text. This made it possible to build a graph of connections on a truly global scale. The rational I guess was to possibly aid anti-terrorist forces to catch the bad guys. From the other side all population's activities were tracked. See PRISM for more info.
I came across many APIs that give the user both an API key and a secret. But my question is: what is the difference between both?
In my eyes, one key can be enough. Say I have a key and only I and the server know it. I create a HMAC hash with this key and do an API call. On the server, we create the HMAC hash again and compare it with the sent hash. If it's the same, the call is authenticated.
So why use two keys?
Edit: or is that API key used to lookup the API secret?
You need two separate keys, one that tells them who you are, and the other one that proves you are who you say you are.
The "key" is your user ID, and the "secret" is your password. They just use the "key" and "secret" terms because that's how they've implemented it.
Simple answer, if I understood it correctly...
If you use your API key for encryption, how will the service know who is contacting them? How will they decrypt that message?
You use API key to state who you are, this is what you are sending in plain text.
The SECRET key you do not send to anyone. You simply use it for encryption. Then you send the encrypted message. You do not send the key that was used for encryption, that would defeat the purpose.
One thing that I did not see mentioned here, although it is an extension of Marcus Adams's answer, is that you should not be using a single piece of information to both identify and authenticate a user if there is a possibility of timing attacks, which can use the differences in response times to guess how far a string comparison got.
If you are using a system which uses a "key" to look up the user or credential, that piece of information could be incrementally guessed over time by sending thousands of requests and examining the time that it takes for your database to find (or not find) a record. This is especially true if the "key" is stored in plaintext instead of a one-way hash of the key. You would want to store users's keys in a plaintext or symmetrically-encrypted for if you need to be able to display the key to the user again.
By having a second piece of information, or "secret", you can first look up the user or credential using the "key", which could be vulnerable to a timing attack, then use a timing-safe compare function to check the value of the "secret".
Here is Python's implementation of that function:
https://github.com/python/cpython/blob/cd8295ff758891f21084a6a5ad3403d35dda38f7/Modules/_operator.c#L727
And it is exposed in the hmac lib (and probably others):
https://docs.python.org/3/library/hmac.html#hmac.compare_digest
One thing to note here is that I don't think that this kind of attack will work on values that are hashed or encrypted before lookup, because the values that are being compared change randomly each time a character in the input string changes. I found a good explanation of this here.
Solutions for storing API keys would then be:
Use a separate key and secret, use the key to look up the record, and use a timing-safe compare to check the secret. This allows you to show the user the key and secret to a user again.
Use a separate key and secret, use symmetrical, deterministic encryption on the secret, and do a normal comparison of encrypted secrets. This allows you to show the user the key and secret again, and could save you from having to implement a timing-safe comparison.
Use a separate key and secret, display the secret, hash and store it, then do a normal comparison of the hashed secret. This removes the necessity to use two-way encryption, and has the added benefit of keeping your secret secure if the system is compromised. It has the downside that you cannot show the secret to the user again.
Use a single key, show it to the user once, hash it, then do a normal lookup of the hashed or encrypted key. This uses a single key, but it is not able to be shown to the user again. Has the benefit of keeping keys secure if the system is compromised.
Use a single key, show it to the user once, encrypt it, and do a normal lookup of the encrypted secret. Can be shown to the user again, but at the cost of having keys vulnerable if they system is compromised.
Of these, I think that 3 is the best balance of security and convenience. I have seen this implemented on many websites when getting keys issued.
Also, I invite any actual security experts to critique this answer. I just wanted to get this out there as another discussion point.
There are answers explaining what the secret and (public) key is. It's a public-private key pair that they give confusing names to. But nobody says why the APIs require both, and many APIs only give you one secret! I've also never seen any API's docs explain why they have two keys, so the best I can do is speculate...
It's best to put only your public key in your request and sign the request locally with your private key; sending anything more shouldn't be needed. But some get away with just having the secret in the request. Ok, any good API will use some transport security like TLS (usually over HTTPS). But you're still exposing your private key to the server that way, increasing the risk of them somehow mishandling it (see: GitHub and Twitter's password logging bug recently discovered). And HTTPS is theoretically just as secure, but there are always implementation flaws out there.
But many – actually most it seems – APIs have you send both keys in requests since that's easier than making people do their own signatures; can't have pure cURL examples otherwise! In that case, it's pointless to have them separate. I guess the separate keys are just for in case they change the API later to take advantage of them. Or some have a client library that might do it the more secure way.