Tag Info

Hot answers tagged

7

What happens if the sender is at another point in the sequence? ... the key is pressed while out of range to the car. In a rolling code (code hopping) system, the keyfob transmitter maintains a synchronization counter C, incremented every time a button is pushed. The car receiver stores the most recent validated synchronization counter it has received ...


6

You got tripped up by the fact that there are two different group operations in play here, and they don't play nice with each other. This is implicit in the notation, and it's easy to get tripped up, because the notation expresses both operations in the same way -- but they are not the same. This is arguably a pitfall in the notation: the assumption is ...


6

There is not much special about near field communication here - it is just like any insecure transport medium, which can be evesdropped on (with external antennas up to several meters in distance). Because of the low distance limit, there is no way for a man-in-the-middle attack if you (the human operator) are sure that your device is communicating with the ...


5

The protocol's description includes "Alice then encrypts $R_B$ with her private key". This has no standard meaning. Comments have clarified it is used an "RSA encryption scheme with proper padding" and I am taking as granted that encryption of $R_B$ using the private key half of $K_A$, denoted $K_A^-(R_B)$, is obtained by padding $R_B$ as in encryption, then ...


5

The archetypal safeguard against that threat is including an originator ID and a sequential number in each message (within the authenticated payload), and making the receiver ignore any message from him/herself, or with a number no higher than the highest in any message from that source so far. The sequence number can be replaced by time.


5

A replay attack simply means that an attacker who intercepts a valid message can re-send that message as many times as they want. If there's nothing in the message that could not be legitimately repeated, then the recipient will have no reason not to accept it as a valid message. In general, all encryption modes are potentially vulnerable to replay ...


4

The standard solution would be to have the sender maintain a counter, and sending the value of that counter in each request (which is tied into the integrity check of the request). The receiver would remember the largest counter value that he has received a valid request for, and a bitmap showing which of the N requests prior to that he has actually seen. ...


4

A replay attack works by blindly re-using an earlier message or ciphertext, or fragment thereof, typically one that was encrypted or signed. A simple example would be a bunker which receive the encrypted message "I'm General X, open the door". Now if this encrypted message was captured a week earlier and replayed by some opponent, well you get the idea. ...


3

In a rolling code both the sender and the receiver always move forward in the sequence. If the sender has sent the $n$th code, then it will send the $(n+1)$th next. Contrarily, if the receiver has seen the $n$th code it will only accept the $(n+1)$th code or some later code. What happens if the sender is at another point in the sequence? Think of that ...


3

If the receiver can wait for all the packets before decrypting: This case is simple, since your final goal is to ensure that the plaintext you decrypt was the exact same plaintext you encrypted. (Trivially, this includes rejecting re-ordered plaintext.) Use an Authenticated Encryption (AE) scheme (eg, CCM, GCM, etc) across all the packets, treating the ...


1

Insecure, you just replay $\text{username}$ and $\text{password}$. Password is also sent in clear text. Secure, if the hash function $H$ used is strong enough to resist bruteforcing of the password. However you'll also need to send the timestamp so that the server can check the auth, so this scheme is better portrayed as $\text{username, timestamp, ...


1

I think you have to specifically define what you're trying to do. Just "authentication" doesn't quite make sense from a practical stand point. I can thinking of saying "hello" to someone for the purpose of "ok, if you get a hello from me then attack!!", but that protocol would look differently than what you're trying to do. Why would you just ...


1

You could use some combination of: an expiration timeout (i.e. if the message does not arrive until the timeout, we don't accept it) storing previous values of a nonce. You only have to store those nonce values whose timeout didn't yet expire. If the messages arrive all in order, you can instead use a simple counter (which always goes up) and reject ...



Only top voted, non community-wiki answers of a minimum length are eligible