Re: [Teep] Scalability of nonce-based freshness

[Thomas Fossati <[e-mail]>]

Hi Göran,

On 12/03/2021, 19:00, "Göran Selander" <[e-mail]> wrote:
> Hi Dave, and all,
>
> Referring to the TEEP protocol presentation at the WG meeting, there
> was a discussion about the use of tokens and what method of freshness
> to apply in TEEP (slides 11-16 in the presentation).
>
> If I understood right the main argument against the nonce-based method
> (slide 15) is the question of scalability: "Receivers have to keep
> state to remember each nonce supplied until it’s used"
>
> If I'm not mistaken, this condition on the receiver could be relaxed
> by the receiver generating nonces as encrypted time stamps. This would
> only require the receiver to remember an encryption context used to
> encrypt/decrypt the time stamps used as nonces. The encryption context
> can be small (say, less than 50 bytes for key, IV and counter) and
> doesn't grow with the number of TAs (but would typically be updated
> for each nonce generated, e.g. stepping the counter).
>
> Note that the receiver needs a clock but it need not be synced because
> the time stamps are only used by receiver; once when nonces are
> generated, and then again when freshness is determined from the nonce
> received back in the evidence. Such a clock coincides with the
> assumption of this method according to slide 15: "Receivers need a
> clock to “expire” nonces, but need not be synced".
>
> Perhaps this should be an input to RATS rather than TEEP. But since
> this seemed to be the main argument against the nonce-based method I
> just wanted to share my 2 cents to the discussion.

I think this is all correct.  (BTW, that's what I meant when I said the
TAM should make this a verifier problem as there is no need for the
nonce to be stored at the TAM.)

With your nonce generation scheme:

A. Verifier is initialised with secret key k

B.1: TAM asks Verifier for a nonce;
B.2: Verifier generates nonce n = E(t_req, k) and sends it to TAM;

C: TAM runs the challenge-response protocol with the Attester, sending
   N and obtaining Evidence(n) in return;

D.1: TAM forwards Evidence(n) to Verifier for verification;
D.2: Verifier extract n and does D(n, k):
  D.2.1: If decryption fails, goto drop;
  D.2.2: If decryption succeeds, extract t_req
D.3: Verifier checks |now - t_req| < acceptable_recentness_threshold:
  D.3.1: If so, proceed with verification of Evidence;
  D.3.2: If not, return ESTALE

Note that if B.* is done once every "period", thus avoiding the extra
round-trip per nonce / attestation session, this scheme falls back to
the epoch-id based model.

cheers!






IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.