Bilateral authentication means that each participant obtains assurance of the other's identity and participation in the relevant run: Alice authenticates Bob and Bob authenticates Alice. An observed name in a message is not such assurance. The protocol must prevent an adversary from supplying the evidence while the named peer is absent.
Session key transport means conveying an already selected session key securely to its intended users. Here Tim selects and sends it inside separate public-key-encrypted tickets for Alice and Bob. This differs from having Alice and Bob jointly derive a key to which both contribute.
A trusted third party is an additional participant whose correct behaviour and protection of its secret state are assumptions on which the other parties rely. Here Alice and Bob rely on Tim to associate identities with the right public keys, generate fresh session keys, and keep the long-term shared secrets confidential.
Tim is allowed to know , so the intended cryptographic confidentiality claim excludes the network adversary, rather than excluding Tim. Correct behaviour by Tim does not make every message purportedly sent by Tim authentic: the recipients must still verify the relevant evidence.
In the Dolev-Yao model, an adversary controls the network: it can intercept, suppress, delay, replay and redirect messages, impersonate network senders, and construct messages from values it knows. In particular, it can concatenate or split unprotected tuples, and can apply encryption using any known public key or known symmetric key.
Cryptography is idealised. Without the required private key or symmetric key, the adversary cannot recover a protected plaintext or construct an otherwise unavailable protected value. It cannot invent an unknown long-term secret merely because the containing ciphertext is visible. Protocol failures arise from the arrangement of messages even when these cryptographic primitives behave perfectly.
Alice's own freshness evidence is the ticketAfter decryption, she checks her pending cryptographic nonce, the long-term shared secret and both identities. Only Alice and Tim know ; with honest Tim and an unpredictable new , a valid matching ticket establishes that Tim generated this session key after that challenge was issued. A merely unused but predictable challenge does not establish that temporal ordering.
The claimed authentication of Alice to Bob, however, is false for the printed protocol. To exhibit the failure, let initiate message 1 using Alice's name while Alice is absent. Bob and Tim carry out messages 2 and 3 normally. Write the genuine message 3 as , where and . The adversary intercepts it, learns the unencrypted , and chooses a symmetric key of its own.
The adversary sends BobBob's checks of and the ticket identities pass, because anyone can encrypt using his public key. Bob sends message 4 using ; the adversary suppresses that message and returns as message 5. Bob accepts Alice, although Alice has done nothing. No encryption has been broken.
The tempting intended argument is that only Alice, Bob and Tim could know the transported key, so message 5 proves Alice's participation. The substituted ticket invalidates its premise: Bob's accepted key is , which the adversary knows.
Alice can still authenticate Bob when she accepts a genuine fresh ticket and successfully checks . The session key inside her ticket is Tim's genuine key, protected by her public key together with . Tim gives that same key only to Alice and to the holder of Bob's private key. The adversary cannot derive it, and honest Tim does not send the greeting. Alice has not sent that greeting either. Thus the matching greeting is evidence that Bob obtained the key and participated. The different final greetings prevent simply reflecting Alice's own confirmation back at her.
Bob's intended freshness test is that was hidden in his request encrypted for Tim, so a matching answer must follow Tim's processing of that request. This establishes that Tim revealed that cryptographic nonce; it does not authenticate the adjacent ticket. The substitution attack in solution may use an old adversary-known instead of a fresh one. Bob accepts it even though its freshness is false.
The defect is the absence of a cryptographic binding between Bob's cryptographic nonce and his key ticket. A repair must bind the identities, both cryptographic nonces and the session key under message authentication verifiable as Tim's, for example a digital signature by Tim over the response, checked before Bob accepts. Merely moving the nonce inside a public-key-encrypted ticket is insufficient once an attacker knows or predicts it: anyone can create such an encryption.
The final messages contain fixed greetings, rather than a fresh challenge for their particular run. Their freshness is inherited entirely from the session key. If a key is reused, a previously recorded or becomes acceptable evidence again. An adversary can then mount a replay attack without knowing and without the purported speaker taking part in the new run.
Reusing a previously compromised session key is worse: the adversary can create both confirmations and read protected traffic. Fresh independent session keys limit that reuse, although they cannot fix the unauthenticated-ticket flaw shown in solution.
An unpredictable random -bit cryptographic nonce is better for Alice than a predictable counter, provided repetitions are detected or made sufficiently unlikely. Alice wants a matching ticket to imply a response to her present challenge, and the protocol lets anyone ask Tim for a ticket containing a chosen .
Suppose an adversary predicts that Alice's next challenge for Bob will be . Before Alice starts that run, the adversary sends to Bob as message 1. Bob asks Tim for a session key and returns the genuine pair in message 4. The adversary stores that pair and lets the early run lapse. Later, when Alice really emits , the adversary blocks it and delivers the stored pair. Alice's ticket and greeting checks pass, despite the key and Bob's participation predating her run. This is a preplay attack on freshness and recent participation. Bob need not accept Alice's eventual message 5 for Alice's acceptance to have failed its freshness goal.
Success requires the predicted value and identities to match, an early run that yields the matching ticket and greeting, and Alice to accept solely from the outstanding value without additional expiry or run binding. No session key disclosure is needed to defeat freshness; if that old key has also been compromised, impersonation and loss of cryptographic confidentiality follow as well.
A guess at a particular uniformly random value has probability per independent attempt, with success approximately for distinct guesses when that ratio is small. Random choice does not itself guarantee uniqueness: among independent values the birthday problem collision scale is approximately . Counter uniqueness and unpredictability are different requirements.
Bob especially needs unpredictability, because is intended to be secret until Tim processes the request. A predictable counter destroys even that limited assurance.
If the adversary knows Bob's next value , it initiates a run with Alice's name and intercepts Bob's request. Without consulting Tim, it chooses a key , constructs , and sends as message 3, with any suitably shaped opaque ticket for Alice. Bob cannot inspect that ticket. He accepts , sends message 4, and accepts the adversary's . Alice and Tim need not participate.
This preplay attack requires a correct prediction of Bob's outstanding value, knowledge of his public key, and the ability to intercept or race the genuine response. Observing an earlier unencrypted response may expose a counter value from which to predict the next. With an independent uniformly random hidden -bit value, blind prediction succeeds with probability per attempt.
In particular, random cryptographic nonces do not make the printed protocol sound. After the genuine message 3 reveals , the adversary can use exactly the substitution in solution. Predictability allows an earlier attack without Tim; lack of response binding allows an attack even with perfect unpredictability.
A denial-of-service attack can exploit both an honest relay and replay at Tim. The adversary repeatedly sends cheap unauthenticated message-1 requests naming Alice and Bob. Bob then performs the public-key encryption in message 2, and Tim performs a private-key decryption, generates a session key, looks up the users' records and performs two public-key encryptions. The adversary's first messages contain no cryptographic work.
Alternatively, after observing one valid message 2, the adversary submits copies directly to Tim. It remains well formed; the printed protocol has no request-replay cache. Tim's promise to reject malformed requests does not imply duplicate suppression. Each replay can provoke the expensive operations again. If such a cache is added, the repeated-message-1 method still induces distinct requests through Bob unless admission is controlled.
Place a proof of work gate before Tim performs the expensive private-key decryption in message 2. Binding the puzzle to the whole request prevents solving a cheap puzzle once and reusing it with different tickets.
For example, let be the exact encoding of message 2, including identities, Alice's cryptographic nonce and Bob's encrypted component. On receiving a proposed request, Tim does only cheap length and format checks and returns a fresh challenge , an expiry time , a difficulty and a cookieHere is Tim's cookie secret and the message authentication code prevents alteration of the challenge or difficulty. Tim need not retain large amounts of per-request state merely to issue the cookie.
The requester finds a suffix such thatUnder the usual unpredictable-hash-output model, this takes an expected trials; verifying a proposed suffix needs one cryptographic hash function evaluation after checking the request digest and cookie. Preimage resistance motivates search difficulty, but the exact estimate also uses that distribution assumption.
The requester returns . Before any expensive decryption, Tim verifies the cookie, expiry, work and request binding, and atomically records that this challenge has been consumed. Repeated submissions of a consumed challenge are rejected cheaply. Short expiry bounds the storage needed for spent challenges. A cookie alone is insufficient: without one-use enforcement, the attacker could replay a single valid solved request indefinitely.
To charge the work to the initiator rather than Bob, Bob can relay the challenge to Alice and forward her solution. The adversary's fake Alice must then solve each puzzle instead of making honest Bob do it. Tim must issue challenges and reject bad proofs with bounded inexpensive processing, and difficulty should be chosen so that many verified requests require substantial aggregate work. This mitigates the computational denial-of-service attack; it does not correct the separate authentication flaw.
Articles by others on the same topic
There are currently no matching articles.