If I do an authentication to a DESFire card using AES, do I need to do the key diversification? If so, is there some code example of how to do the diversification?
No, you don't have to use a diversified key. You can just as well use the same key(s) for all your DESFire cards. However, it is advisable to use a diversified key in order to prevent attacks on the whole system if an attacker discovers the key(s) for one card.
With regard to key diversification functions, I suggest that you take a look at NXP's application note on Symmetric key diversifications.
Related
I use a TPM 2.0 with verified and measured boot. Now I read about external TPM modules for mainboards, which do not have a TPM module yet. I am a bit confused on how secure this is.
I think a attack vector could look like this:
Put a man-in-the-middle device between mainboard and TPM which records every data sent
This way an attacker could exfiltrate e.g. windows bitlocker keys.
Are there any methods to prevent such attacks?
I am also interested about the security about TPM modules on motherboards, since there the same attack could be done.
How is the firmware measured into the TPM? Does this rely on data from the TPM?
Yes such man-in-the-middle attacks against the TPM are well-known; articles describing them seem to come out with regularity, almost on an annual basis (see here for the latest one).
The way to protect against them is session-based encryption. (see section 21 here)
To present the simplest use case, where the session is not an authorization session and is not bound to a TPM object: basically, you would start a salted session, which will ensure that only you and the TPM have access to the salt. Interception of the session start message would not help, as the salt is encrypted with a TPM key.
Then the session key is computed:
sessionKey ≔ KDFa(sessionAlg, salt, “ATH”, nonceTPM, nonceCaller, bits)
Note that the TPM is going to have to decrypt the salt on its end.
The XOR mask for encrypting the message is computed thusly for each exchange:
mask ≔ KDFa (hashAlg, sessionKey, “XOR”, nonce1, nonce2, data.size • 8)
The protected data is then encrypted by XORing it with the computed mask for parameter encryption. Note that the mask is going to be different for each encryption operation, as the nonces are constantly refreshed.
There is also an option to use CFB mode encryption on devices that support it.
Might be an unqualified question, but are there any encryption systems where two encryption keys are generated (one public, one private), and...
A) The public key is used for encrypting the information, but cannot be used to decrypt it
B) The private key is used for decrypting the information, and cannot be used to encrypt it.
I am asking because I see this as the only practical way to secure a login session to a web service (such as a forum) without the use of SSL/HTTPS. Though, with my limited knowledge of system security and cryptography, it's more than likely that I'm wrong.
The most common private key encryption algorithm is RSA. However, if you don't know what you're doing, stick to higher level constructs such as SSL/TLS.
I have 2 devices and I want to set up a secure communication channel between them. The only shared secret is a (7- to 20- character ASCII) passphrase. If I use PBKDF2 (from RFC 2898) with a common salt, iterations, and passphrase to generate an AES256-CBC key and IV on both sides, I think I can authenticate the user and provide an encrypted channel all in one step. Is that true, or is there some reason why I've only seen people use PBKDF2 to verify passwords?
My reasoning is that both sides need to know the passphrase to generate the same key and IV. So if device B can decrypt data from device A, they both have demonstrated that they have the same passphrase.
PBKDF2 is a fine way to generate a common key from a shared secret (you should not be generating the IV in such a way though - the IV should be random, and sent alongside the ciphertext).
However, CBC is not an authenticating cipher mode. This is because an attacker can take an encrypted message and make predictable modifications to it, without needing to be able to read the message or know the key. Such attacks have broken real world systems in the past.
You can use an authenticating cipher mode, like Galois Counter Mode (GCM) instead of CBC.
An alternative is Encrypt-Then-MAC. Use PBKDF2 with two different salts to generate two different keys - first the data is encrypted using CBC with the first key, and then a HMAC is calculated over the ciphertext using the second key.
You will also need to use single-use-nonces to prevent replay attacks.
In general, you wouldn't be able to authenticate a message using a cipher, because the message could be anything. However, if the message conforms to some specified format, I suppose it's reasonable to assume the ciphertext must have been produced with the shared key—with longer messages in more complex formats giving better assurance. For example, the padding in a block cipher can serve as a weak authentication.
For better security, compute a MAC using the shared secret and send that with the ciphertext.
While PBKDF2 can be used to produce an IV, it can only do so for a single message. In most cases it's better to select a random IV and send it with the ciphertext.
PBKDF2 does not "verify passwords". It generates keys from passwords.
To verify a password, normally you have a thing that gets encrypted with a key. The key is generated from the original password, via PBKDF2. Then the cryptotext is saved.
When you want to check whether the user-entered text matches the password, generate the key from the password candidate using PBKDF2, then try to decrypt the saved cryptotext. If the decryption works, then you have a match.
Normally, though, you would not use the password-based key as a session key.
So, NO, you normally would not protect the secure channel with the password-based key.
caf's answer is good. I'd just like to add that you're trying to implement crypto, and even for trained experts that's generally a bad idea. Using the highest-level library you can is much safe.
I was arguing about an S3 like aproach using authorization hash with a secret key as the seed and some data on the request as the message signed with hmac sha1 (Amazon S3 way) vs an other developer supporting symetric encryption of the data with a secret key known by the emiter and the server.
What are the advantage of using signed data with hmac sha1 vs symetric key other than the fact that with the former, we do not need to encrypt the username or password.
What would be the hardest to break ? symetric encryption or sha1 hashing at la S3 ?
If all big players are using oauth and similar without symetric key it is sure that there are obvious advantages, what are those ?
An hmac and a symmetric cipher are not mutually exclusive ideas. In fact AES-CMAC which is both an MAC (not hashed) and a symmetric cipher, AES-CMAC is the cryptographic primitive that makes WPA secure. (Although a WPA can still be broken using a rainbow table).
You should not need an exotic authentication system for this. Logging in with a username and password and maintaining session state with a cookie is commonly used because it is easy to implement and it is secure. By storing state, like a cookie its no longer technically RESTful, but there is nothing stopping you from doing it.
However, in terms of authentication I believe that asymmetric cryptography like RSA is the most secure. (Amazon uses asymmetric cryptography for ssh connections by default.) This allows you to only store the public keys, so that if your server where to be compromised no authentication credentials could be used. It also defends against MITM attacks. In many cases this can be implanted quite easily with REST because HTTPS already supports client certificates. You can sign the clients certificates for free and then verify them your self.
If implemented properly, the strength of an hmac vs symmetric cipher it mostly comes down to the strength of the secret. If you are using a secret like a password, then both systems are equally very weak. These secretes must be large, Cryptographically Secure Psudorandom Numbers. Another thing to keep in mind is that symmetric ciphers are very difficult to implement properly. Most programmers do not understand this and end up reusing PRNG when using stream cipher or when using a block cipher they use an incorrect mode and leave the IV null. By contrast HMACS are very easy to implement and less can go wrong. If everything is transmitted over HTTPS, and your are using an hmac then its easy to implement a secure authentication system. If you really want to implement a symmetric cipher you must get a copy of Piratical Cryptography, there are a few chapters devoted to symmetric ciphers alone because so much can go horribly wrong. You also have to take key distribution into consideration, ssl uses a DH-Key Exchange for its symmetric keys.
Make sure to read the OWASP top 10, especially Broken Authentication and Session Management. This requires the use of https for the entire session, most web application programmers don't realize this.
The big differences would be that HMAC would provide integrity but no privacy, while encryption would provide privacy without integrity. Many use cases would require both, but I can't think of any where integrity is unnecessary. HMAC seems like a minimum requirement, with encryption being a likely companion.
If we consider Man In the Middle Attack;
Can such an attack occur if symmetric keys are used?
Sure. All you need to do is intercept the key exchange. Then you can pass on your own (fake) key to the other end. You intercept the messages using the key you obtained fraudulently and re-encrypt with your fake key and pass on to the other end.
The trick is to agree on the symmetric key in the first place.
Man-in-the-middle attacks usually occur during the key exchange phase (making you agree on the key with the middle-man instead of your real partner).
So what usually happens (in web browsers' SSL sessions) is that you use asymmetric cryptography to exchange the symmetric key. However, that depends on your partner's public key really belonging to who you think it does. Usually, you take Verisign's or (some other CA's) word for that.
At some point, a secure and authenticated key exchange has to have taken place.
Since the MIM attack can happen during the key exhange, you could do what SSL/TLS does.
SSL/TLS uses RSA in the key exchange, so that the exchange of the symmetric key is [heavily] protected with RSA.
Above answers correct of course, but you should note that there are several efficient, cryptographically secure methods for securely exchanging keys. I think the one wow uses is SRP6.
Yup. Even if you use symmetric key you have to use authentication/integrity checks. Using symmetric key encryption without authentication/integrity checks makes you susceptible to various forms of replay attacks or substitution attacks. An attacker can modify your ciphertexts and may even know what the effect of his changes are.