3
$\begingroup$

I'm trying to create a sort of Time-based One Time Password (TOTP) where machines are involved (not humans). In this kind of TOTP the step is 15 minutes between one code to the next one and both server and client share the same 256 bit secret key (k). The message (m) is the current unix timestamp that is known by an attacker so suppose the text plain message m is known. The key k is always the same and the attacker also knows the algorithm used for cryptography.

I think about two possible solutions for this problem:

  1. HMAC(k,m) using sha256 as base algorithm client side, send the result and check server side that the hash is the same, then ok.
  2. AES(k,m) and send crypted message as base 64 to the server. The server decrypt the message and check the time. If the time is included in accepted range then ok.

Possible scenario:

An attacker knows the plain text (time) and the crypted message (that can be the HMAC hashed text for option 1 or the crypted text after AES for option 2) and have maybe 500 possible combination of textplain plus related encrypted text.

Questions:

Q1: is it possible for the attacker to know the key k before a time range of 5 years for both of options with current computational power?

Q2: Which is the most secure option to use? Option 1 or option 2?

I'm studying these algorithms for days but I haven't find an answer to my questions yet.

Note: I studied TOTP in RFC 6238 too but it seems more related to Machine-human than machine-machine TOTP. For machines, with a 15 minutes step, seems more insecure than the 2 options proposed.

Thanks for everyone can help me in these questions, are making me crazy.

Improve this question
$\endgroup$
1
  • 1
    $\begingroup$ I'd consider both to be more than secure enough for your specification; much more than 5 years in fact. But to choose between them: I'd avoid encryption when a hash will do just on general principles. You have a 15-minute window so as long as the m is rounded down to the nearest 15-minute mark, and both sides have decent clocks, you don't need the ability for the receiver to decrypt the incoming message. $\endgroup$
    – user30713
    Commented Oct 22, 2020 at 2:28

1 Answer 1

Reset to default
2
$\begingroup$

Be reassured: both $\text{HMAC}(k,m)$ [instantiated with a strong hash function, e.g. SHA-512; even SHA-256 would do] and $\text{AES}(k,m)$ [understood as direct encryption of 128-bit $m$ with the block cipher] are believed to be computationally secure Message Authentication Codes for the foreseeable future when the key is 256-bit, irrespective of how many message/cryptogram pairs are available. Both can be truncated: 64-bit would be ample if the verifier limits the attack rate.

$\text{HMAC}$ has the security advantage of being less susceptible to cache-based side channel attacks than $\text{AES}(k,m)$ is, for implementations in software without AES-NI on CPUs with caches.

From a functional perspective, $\text{AES}(k,m)$ has the slight advantage that (if kept 128-bit) it conveys the timestamp $m$, which can be recovered by decryption. Otherwise we may need to transfer or guess some low bit(s) of the timestamp to fix any drift there may be, especially at startup.

Whatever the MAC, one operational vulnerability is likely to be the establishment and storage of the long-term 256-bit key $k$. There might be other attacks on the protocol, which is not described.

Improve this answer
$\endgroup$
6
  • $\begingroup$ I don't like the fact that you could send any ciphertext to a service and then hope that the decrypted result is within an acceptable interval for the AES solution. That depends too much on the implementation and is therefore too brittle for me. Especially for M2M, I don't see any reason for a small(-ish) code to be send, 16 or 24 bytes probably don't make much of a difference. $\endgroup$
    – Maarten Bodewes ♦
    Commented Oct 18, 2020 at 15:59
  • $\begingroup$ @Maarten Bodewes: in some battery-operated M2M applications (some sensors, metering systems, remote controls), a large portion of the precious energy is consumed by the data transmitter, and thus grows linearly (perhaps nearly proportionally) to the amount of data sent. Every bit may count, that really depends on context. Sometime comfort sometime is an unfordable luxury. I recently had to fit a time-based MAC in a message sent by a Bluetooth beacon. There was little space left, I could only fit the low bits of the time (the high bits can be recovered), and a short MAC. $\endgroup$
    – fgrieu ♦
    Commented Oct 18, 2020 at 16:23
  • $\begingroup$ OK, but with AES encryption you're basically stuck at 16 bytes, so I'm not even sure if it is worth it in those situations. I'd certainly not recommend just AES without warning or indication of the scheme used. $\endgroup$
    – Maarten Bodewes ♦
    Commented Oct 19, 2020 at 6:59
  • $\begingroup$ I'm confused why the timestamp m needs to be conveyed and recovered at the other end. The protocol can just round the current time down to the last 15-minute mark, just like normal TOTP does to the 30 second mark, can't it? $\endgroup$
    – user30713
    Commented Oct 22, 2020 at 2:31
  • 1
    $\begingroup$ @sitaram: you are correct that $m$ does not need to be transferred when both sides maintain time on some common scale with an accuracy sizably better than the step: there can be at most 2 valid timestamps, and it's possible to find which by trial and error, or just one message bit. I fixed the answer. I was sent off by the question's "current unix timestamp" and my background with such systems that maintain time locally with drifts that get in the order of minutes. $\endgroup$
    – fgrieu ♦
    Commented Oct 22, 2020 at 4:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.