2

I came across a peculiar system for generating "signatures" ("signatures" is within quotes because this is a bad use of 3DES) in the wild.

It works as follows: a symmetric key is generated and used to encrypt the current time using 3DES, in CBC mode with 8 zero valued bytes as an IV. The resulting signature is used like a session token - the server will decrypt the signature and check if the time is within some bound.

Is it possible to forge a signature?

Maarten Bodewes
  • 92,551
  • 13
  • 161
  • 313
Kyb3r
  • 33
  • 3
  • What security guarantees does the "signature" try to provide? Is it essentially a stand-alone encryption of the time or is the time prepended to an actual message? – SEJPM Sep 20 '18 at 17:17
  • 1
    Assuming the "signature" doesn't involve the message at all it's trivial to construct a UF-CMA attacker that queries one message and then just uses the received signature on an arbitrary message. – SEJPM Sep 20 '18 at 17:19
  • The "signature" is used to authenticate users -- ie the server decrypts the "signature" and checks if the time is within some range. – Kyb3r Sep 20 '18 at 17:20
  • You mean, the client and server agreed on symmetric key by a protocol? – kelalaka Sep 20 '18 at 17:32

2 Answers2

1

Probably Not

Simplifying the discussion, one-block CBC with a null initialization vector reduces the mode to ECB.

Seeing that most time stamps are less than or equal to 8 bytes, only one block should be used (maybe two if there is a padding scheme).

There currently aren't any known algorithms for ECB forgery (as far as I'm aware), so I'd say it's unlikely.

However, this scheme could theoretically be susceptible to a brute-force attack.

If the time window were one day, the search space would only be about 48 bits (2^16 seconds being roughly one day).

Practically, this is an unrealistic attack, (and requires the server to ingest approximately 2.25 Petabytes of data), but it's feasible within an order of magnitude, which is not usually desirable.

Jesse Daniel Mitchell
  • 111
  • 1
  • I'm not sure about the brute force attack. I would expect attacks to be dependent on the key and output size rather than the input message. Or to sidestep the algorithm altogether and to focus on the protocol rather than the MAC algorithm used. – Maarten Bodewes Sep 20 '18 at 20:50
  • 1
    I actually did base my attack on the output size of Triple DES (64 bits), the probability of you landing within the permitted range by randomly guessing is 1/2^48, assuming they're using 8 byte timestamps with a 1-day time window. – Jesse Daniel Mitchell Sep 20 '18 at 20:53
  • Ah, OK, that makes sense, although I would certainly create a smaller window myself when using a time stamp for authentication. If you can crash the application before the time stamp is saved then replay attacks become easy. That said, we don't know the full protocol and counter measures, so basically we can only guess :) Welcome to crypto by the way, upvoted answer. – Maarten Bodewes Sep 20 '18 at 20:59
  • Thanks! I think your answer is far more practical and delivers additional context, and should be the accepted answer (I can't upvote yet, or I would). I just wanted to explore potential attack vectors (within the scope of the MAC). – Jesse Daniel Mitchell Sep 20 '18 at 21:12
1

This sounds like a very standard application of CBC-MAC with (known) fixed length messages. This is considered to be secure. I would not call the use of 3DES for CBC-MAC "bad use of 3DES" - to use quotation marks myself.

Time stamps by themselves are tricky to be used for authentication; they don't include an ID of the sender and may be susceptible to replay attacks. They require the verifier to maintain state and - if there are multiple verifiers - to synchronize. If anything is insecure it is likely the protocol or implementation rather than the CBC-MAC.

Using AES-CMAC or HMAC would certainly increase the security strength, if just because of the larger output size (authentication tag) that can be produced.

Maarten Bodewes
  • 92,551
  • 13
  • 161
  • 313