Re: AES MAC security question

From: Joseph Ashwood (ashwood_at_msn.com)
Date: 07/03/05 

Date: Sun, 03 Jul 2005 03:37:37 GMT

"Rein Anders Apeland" <apeland@mivu.no> wrote in message
news:1120330914.5120.18.camel@localhost.localdomain...

Ok let's see if I've got it straight from what's been said:
10kbps
transmitter ID
Sequence Counter
Command
MAC

Making some size assumptions here to make things easier.
ID = 64 bits
Sequence Counter = 32 bits, will be discussed
Command = 8 bits
MAC = 32 bits

Ok there is a solid reason I have created the 32-bit counter, because you
are basically using the as your IV it has to be either at least the output
length (32-bits) or at least long enough to not wrap, preferrably both.

The consideration of only allowing 1 command from the correct transmitter ID
per second is a very good one. Beyond that I would also suggest only
changing the stored counter as a result of a valid command. I would also
suggest creating a hidden field, you already have some left over bits, these
should be sahred secrets. From an information theoretic viewpoint they would
be null, but they do represent a hurdle if they are never broadcast, this
will defeat a number of different attacks, it could even be done by making
all the transmitter IDs actually 112-bits (64 bits from the above format, 48
bits to fill the block), this will create a small amount of additional data
that will complicate a functionable attack.

Using CBC won't actually improve anything, unless you create the longer
shared secret, which 48-bits is probably already more than enough.

I assume there is some form of sync up that happens to link a fob to a
receiver during which the shared secret will be transferred.

Given this I don't see any way to attack the system without prying open the
box and removing chips. Although there are elctro-magnetic interference
methods that you need to gaurd against (Faraday cage).

With these steps in place I can't think of a better alternative that doesn't
inflate either the computational overhead or the bandwidth requirements in
unacceptable ways.
                Joe