So, as far as I understand here what is happening on digital signature:
Bob creates message and timestamp: M + Timestamp = L
Bob hashes the L: H(L)
Bob signs the H(L) with his private key: Sign(H(L))
Bob sends this signature and L to Alice: L || Sign(H(L))
Alice open H(L) with Bob's public key.
Alice hashes the L: H(L)
Alice compares if the H(L)s match.
If so source integrity has been established. Thus, we can ensure that message is sent by Bob.
So why do we include timestamp into message? We already know message is from Bob, what is the point of checking timestamp as if it is delayed or not?
If Alice checks the age of the message, and/or collects timestamps of already-received messages, she can defend against replay attacks.
A replay attack is when somebody has captured a genuine message from Bob but sends it again (or instead) at a later date.
Related
Amy and Betty have a shared key, and the protocol bellow is to provide a mutual authentication for both Betty and Amy. Bellow is the protocol.
A sends B : na I am Amy...here is a nonce
B sends A : nb+E(k,na) here is another nonce... your nonce encrypted with k
A sends B : E(k,nb) OK...here is your nonce encrypted with our shared key k
na -- nonce by Amy
nb -- nonce by Betty
Can spoofing take place here where someone pretends to b Amy even without knowing the shared key?
I've used the wikipedia article among other sources to understand how this protocol works and have two questions:
1) After Alice makes her initial query to the server, she receives as part of the response:
(the new session key + Alice's ID) - encrypted with Bob's secure key.
Since the secure keys in this particular protocol are symmetric and Alice knows the full contents of this "packet", won't she be able to now go and figure out Bob's secure key?
2) The wiki article explains the Achilles heel of this protocol to be a replay attack "If an attacker uses an older, compromised value" for the session key they can repack it as:
(the session key + Alice's ID) - encrypted with Bob's secure key
and use that to initiate a session with Bob.
Maybe I'm just missing something, but just because the attacker has the session key does not mean that they have Bob's secure key. How are they then to generate the above packet?
What you are referring to is a Known Plaintext attack. http://en.wikipedia.org/wiki/Known-plaintext_attack. In Kerberos 5, the encryption protocol used is AES, and it is generally considered to be 'resistant' against KP attacks. See here: https://crypto.stackexchange.com/questions/1512/why-is-aes-resistant-to-known-plaintext-attacks for a discussion of how/why AES is considered resistant.
Attacker (M) does not need to repack anything using K_B, it only records all previous communication from A to B. Later, it re-sends {K_AB, A}K_B to B. Without a nonce B does not know that this session key is not fresh. It starts a new session with A. Since A is not expecting any packet from B, all the packets coming from B in this session is dropped. But M keeps replying to B making it think that A is replying.
Note that rest of the communication in this session does not need K_B, but just K_AB. The new nonce B sends is encrypted with K_AB (that M already knows and can use to decrypt the new nonce). M can decrypt older messages from A to B, update the nonce values (according to the new nonce for this session) and repack using K_AB. This way M can make B redo the sequence of action it did in previous session.
How is that helpful? Say, B is a bank and A sent $10 to M in previous session using B. M can later replay the previous communication over and over to repeat that transfer from A to M.
I'm developing own protocol for secure message exchanging.
Each message contains the following fields: HMAC, time, salt, and message itself. HMAC is computed over all other fields using known secret key.
Protocol should protect against reply attack. On large time interval "time" record protects against replay attack (both sides should have synchronized clocks). But for protection against replay attack on short time intervals (clocks are not too accurate) I'm planning replace "salt" field with counter increasing every time, when new message is send. Receiving party will throw away messages with counter value less or equal to the previous message counter.
What I'm doing wrong?
Initial counter value can be different (I can use party identifier as initial value), but it will be known to the attacker (party identifier transmitted in unencrypted form).
(https://security.stackexchange.com/questions/8246/what-is-a-good-enough-salt-for-a-saltedhash)
But attacker can precompute rainbow tables for counter+1, counter+2, counter+3... if I will not use really random salt?
I'm not certain of your design and requirements, so some of this may be off base; hopefully some of it is also useful.
First, I'm having a little trouble understanding the attack; I'm probably just missing something. Alice sends a message to Bob that includes a counter, a payload, and an HMAC of (counter||payload). Eve intercepts and replays the message. Bob has seen that one, so he throws it away. Eve tries to compute a new message with counter+1, but she is unable to compute the HMAC for this message (since the counter is different), so Bob throws it away. As long as there is a secret available, Eve should never be able to forge a message, and replaying a message does nothing.
So what is the "known secret key?" Is this key known to the attacker? (And if it is, then he can trivially forge messages, so the HMAC isn't helpful.) Since you note that you have DH, are you using that to negotiate a key?
Assuming I'm missing the attack, thinking through the rest of your question: If you have a shared secret, why not use that to encrypt the message, or at least the time+counter? By encrypting the time and counter together, a rainbow table should be impractical.
If there is some shared secret, but you don't have the processor available to encrypt, you could still do something like MD5(secret+counter) to prevent an attacker guessing ahead (you must already have MD5 available for your HMAC-MD5).
I have attacked this problem before with no shared secret and no DH. In that case, the embedded device needed a per-device public/private keypair (ideally installed during manufacturing, but it can be computed during first power-on and stored in nonvolatile memory; randomness is hard, one option is to let the server provide a random number service; if you have any piece of unique non-public information on the chip, like a serial number, that can be used to seed your key, too. Worst case, you can use your MAC plus the time plus as much entropy as you can scrounge from the network.)
With a public/private key in place, rather than using HMAC, the device just signs its messages, sending its public key to the server in its first message. The public key becomes the identifier of the device. The nice thing about this approach is that there is no negotiation phase. The device can just start talking, and if the server has never heard of this public key, it creates a new record.
There's a small denial-of-service problem here, because attackers could fill your database with junk. The best solution to that is to generate the keys during manufacturing, and immediately insert the public keys into your database. That's impractical for some contract manufacturers. So you can resort to including a shared secret that the device can use to authenticate itself to the server the first time. That's weak, but probably sufficient for the vast majority of cases.
I'm using PGP to encrypt and send messages to friends.
I've read up that the message is encrypted using a symetric key and then the symetric key is encrypted using the recipients public key. If you have multiple recipients then the symetric key is encrypted multiple times, once for each recipient, and added to the encrypted message. If you set a flag you also encrypt the key with your own public key and added to the message so that you can yourself decrypt it later from your sent items folder.
Now I imagined that the encrypted symetric keys would be embedded in the message as a table with columns email address and encrypted symetric key. So one recipient e.g. john would look through this table for his email address, say john#somewhere.com, find it and then know that that entry was for him to decode and get the symetric key.
My question is why can't I see a list of the recipients in the encrypted message? Without that the recipient would have to go through each entry in the table and attempt to decrypt it until he finds one that he can. Given that the result is a random number, the symetric key, how would any recipient know it was decrypted properly, well I guess unless he also attempts to use any attempt as a symetric key until he finds one that works.
So again, I sort of assumed that I should be able to see a list of recipients in the encrypted message without decrypting, but I can't. What's going on?
In the OpenPGP terminology the packet that holds the symmetric key encrypted with the public key of the recipient is knows as 'Public Key Encrypted Session Key Packet'. Defined in RFC 4880 https://www.rfc-editor.org/rfc/rfc4880#page-17
In this packet only the Key ID of the public encryption key is stored (not its User Id - which is an email address in most cases). And the recipient finds the packet that she should decrypt by searching by Key ID (actually this should be done by the PGP software).
The recipient will always know that the symmetric key is decrypted properly, because otherwise the decryption algorithm will fail.
The same applies to decrypting the data packet with a random key - each block cipher will fail at the end when it verifies the checksum of the last block. Even if you remove the checksum calculation of the symmetric cipher implementation, you will receive just garbage data:)
(I'm doing this on my network, just for science). I was using airodump-ng to capture handshake. After that, I was able to open file with captured information in WireShark and find part with 4 handshake messages of EAPOL protocol. I know about millions of years needed for brute-force and I know that I can use aircrack-ng for dictionary attack.
I would like to extract just password from those 4 messages. I assume it is transfered as some sort of salted hash value. What I don't know is, in which message password resides (wireless password, for connection) and how exactly is sent? For example SHA1 of "password"+"ssid"... I would like to be able to compute exact same hash in my program (of course, that would be possible only for my network because I know my password). I'm gonna need that also for some demonstration on university.
Thanks!
The 802.11i "4 way handshake" that you have captured is where both parties agree on shared Group (read: broadcast) and Pairwise (read: unicast) transient keys. I.e. the keys generated here only exist for the duration of the 802.11 Association, or until the next rekey is issued from the AP.
Before you can even begin to decrypt the 4 way handshake messages you need the pairwise master key (PMK), which is what gets derived from the user-entered passphrase using a key derivation function (PBKDF2), or is the result of a WPS exchange which is based on Diffie-Hellman.
The point here is the ASCII passphrase you are seeking to extract is not exchanged in any of the 4 messages, as it has already been shared amongst all parties involved in the transaction (client and AP in this case) and used to generate a 256 bit PMK. And unless you have this PMK, the contents of the 4 way handshake messages are as good as random data.
The best that you can do, if you already know the PMK, is extract the GTK and PTK from M2 and M3 of the 4 way handshake, and from those pull the temporal key which can be XORed with the payload in subsequent frames to get the plaintext data - which wireshark will also do for you if you enter the PMK or passphrase into the IEE802.11 settings and enable decryption.