# Tag Info

24

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 N. ...

11

It is worth pointing out that Samy Kamkar realized and implemented (in 2015) what is now forehead-slappingly obvious in retrospect - it's perfectly practical to have a radio TX+RX unit that snoops a legitimate code and then turns on a momentary jammer transmitter to slightly corrupt the end of it (so it's not recognized as valid by the receiver). The keyfob ...

8

An old but excellent paper on this topic is Tuomas Aura's Strategies against Replay Attacks. The simplest version of the "Hashed Full Information" method would be to include the MAC of the previous message in the next message (you may also be able to use this as the nonce). Then store the most recent MAC along with the session key and check new messages ...

8

The simplest way to deal with replay attack prevention (in some narrow sense of that, where the goal is to avoid that the receiver allows the same command to be played to it several times) is to have an incremental counter in an authenticated section of the packet, incremented by the sender before forming a packet to be sent. The receiver checks the ...

7

Yes, a ratchet is an effective way of preventing replay attacks. For example, the Signal Protocol does this (for reasons other than replay protection), and it is stated in a blog post that the replay protection "comes for free". Since your transport protocol can lose messages, I would assume it also does not guarantee the ordering, so you will have to store ...

7

This protocol doesn't authenticate the mote at all. Consider this attack: Mote B sends a 'hello' message to Base. This message contains the ID# of Mote A and a random nonce [R] (HW generated) encrypted by the base's public key. Base decrypts the 'hello' and verifies the ID# against a whitelist. Base sends an 'ack' message. This message contains some ...

6

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

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 the ...

5

Rejecting replays is the duty of a higher level protocol. Simple authenticated encryption will accept any message with a valid MAC, even if you receive it several times. Decryption is a stateless process, but you need state to keep track of messages you already received. For example you could associate an increasing counter with each message you send. The ...

4

Is it correct that Alice sends the ciphertext $CT=E_K(IV,AAD,D)$ to Bob together a timestamp $t$ like $CT||t$ That doesn't work; here, GCM doesn't protect $t$; the attacker can easily change it to anything he wants, and GCM will never notice. Now, you could expand the AAD to include the value $t$; , that is, we have $CT=E_K(IV,AAD || t,D)$. With that ...

4

Your question appears to be conflating the ideas of IV and antireplay protection; actually, they don't have anything to do with each other. The IV (in CBC mode) is a randomly selected value chosen by the encryptor; it can be sent along with the ciphertext (as we don't care if the attacker knows it). It's there so that if we decide to send the same message ...

4

Replay attack is a form of network attack in which the attacker records messages and replays them later. Generally attacker uses them to get authenticated during one way or two way authentication. Random nonces are used to prevent them instead of timestamp as the latter requires clock synchronization which is tough in practice.

3

The main part of the scheme works, but your reset mechanism in the client has a potential weakness: First, the attacker can easily get the information about what is the next expected counter, by simply replaying any old message and inercepting the answer. Then, at some counter $c$, the attacker intercepts the message $m$, and saves it. If your answers are ...

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 ...

3

It seems you're worried about two distinct attacks: replay attack (attacker reads a packet and re-sends it later), and a "delay attack" (attacker intercepts a packet, blocks it, and sends it later). The replay attack can be avoided with counters or timestamps; as you mentioned, timestamps can be easier. The hard part is keeping clocks synchronized. The ...

3

By looking the encryption procedure, you will see that we use a different sum of the vectors $\vec a_i$'s at each encryption. Thus, every ciphertext has the form $$(\vec a, ~\vec a\cdot \vec s + e + \frac{p}{2} \cdot m)$$ with different terms $\vec a \in \mathbb{Z}_p^n$ and $e \in \mathbb{Z}$. Notice that the probability that two ciphertexts have the same ...

2

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, }H(\text{... 2 Yes, that is a problem. There are protocols like SRP that both eliminate the need for Bob to store the password in plaintext and prevent replay attacks. 2 The way a stream cipher works, traditionally, is that$E_k$produces a pseudorandom bitstream (the keystream) based solely on the key$k$. The message is then encrypted by XORing the message with the keystream. This has a number of consequences, notably that if you know both the plaintext and ciphertext, it's trivial to compute the keystream (if$C=M\oplus K$... 2 Timestamps, as mentioned by user93353, are one possible answer. The drawback is that they require synchronized clocks, which can't always be assumed. Another possible approach to prove liveness (that is, that this isn't a replay) is for the receiver to select a random value (a "nonce"), send that to the server, and have the server sign the command ... 2 What am I missing here? You could re-use the master secret over multiple invocations and just rely on different nonces. This may come handy – for example – on embedded hardware without a proper True Random Number Generator. 2 In a pure replay attack, Eve acts as a genuine participant to the protocol with respect to the other. Therefore, having passively eavesdropped the protocol:$$\begin{array}{lclcll} \mathsf A&\to&\mathsf B&:&\mathtt{Hello}&\ \ \mathsf{[1]}\\ \mathsf B&\to&\mathsf A&:&B,K_{ab}\{B\}&\ \ \mathsf{[2]}\\ \mathsf A&\to&... 2 @poncho's answer is a good general answer. Here's a slightly conciser specific construction you might consider: Are your messages always sent in order, and received mostly in order? Can the sender remember how many messages it has sent so far? Can the receiver remember how many messages it has received so far? If so, you're in luck! You can use the ... 2 In general, no, this is not safe, and in the cases where it is safe it's wasteful. The safe (but wasteful) cases are those where you're already using an Authenticated Encryption with Associated Data (AEAD) scheme or applying a Message Authentication Code (MAC) over the ciphertext. It's wasteful since those both have their own authentication systems, but ... 2 AEAD constructions encrypt messages and append an authentication tag. That authentication tag is computed using the following data: The secret key The nonce The message, before or after encryption Optionally, some additional data During the decryption process, the authentication tag is computed using the same data, and compared with the one that was ... 2 As far as I know, the "random oracle game" doesn't exist. What your are speaking (I think) is about pseudo-random functions. And when the challenger (not the oracle) is in the "RANDOM" mode, he could keep in memory the pair input/output, according to previous queries. Then it doesn't need to output "error", he could return the same output as in the previous ... 2 And I checked some related works, and most of them only considered the dictionary attack and forward security. Actually, a PAKE has two security goals: That someone cannot recover the password from a number of exchanges (with any greater advantage than being able to test$N$potential passwords using$N\$ active attacks). That someone will not be ...

1

Short: These are different. CCA security usually refers to IND-CCA2 -- indistinguishable ciphertexts under adaptive chosen ciphertext attacks. This is a security notion for encryption schemes. This model does not consider any semantics / context of the messages that get encrypted. As you probably know, resistance against replay attacks is a protocol ...

1

These are different - protection against a replay attack could for example be done by recording that a message was already handled or by including a timestamp in the message and not processing the message if it is too old. Note that for a replay attack the attacker doesn't get the plaintext, but does get access to at least 1 previously sent message. In CCA ...

1

There have been several attacks against Keeloq. I cannot speak to the specific algorithm changes through the years to make it stronger against brute force; however, I am knowledgable in the hardware changes as of discussions I was privy to in 2009. The Keeloq ICs were changed shortly after the power attacks came out to make them immune from power attacks ...

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