[Asterisk-Users] Encryption

[Joel Maslak]

On Thu, 25 Dec 2003, Michael Sandee wrote:

> Most block and stream ciphers can recover from loss... And if you don't
> use block chaining, you have no loss at all... (but it's less secure,
> however this is always relative to what you try to protect) (With block
> chaining, you lose the next block)
> (Afaik block ciphers are more secure, but well... i'm no cryptographer,
> nor cryptanalyst... or mathematician... or ...)

It opens up a *LOT* of attacks, most significantly data injection, if you
aren't really careful.

Here's how I would write the protocol...

You have a bunch of "input packets" which consist of some sort of UDP
payload that represents the voice on the channel.  These are "D" (for
"Data")

Each connection has a unique ID.  This ID should be based on time and be
unique.  An example would be "Time of connection origination in seconds
since 1970 concatinated with a random number".  So this number would
probably be a 64 bit number - the first four bytes would be the seconds
since 1970, the next four bytes would be random.  This is "CID".

Each packet would then have a sequence number - not for the traditional
reassmbly reasons, though, simply to keep old packets from being
reinjected.  This probably isn't necessarily though if * uses sequence
numbers in IAX currently.  I'm assuming that it is already in the data
stream now.

To encrypt, you would take a block cipher.  The result packet would be
("." is string encapsulation, E() is encrypt):
  P = CID . E(CID . D)

To decrypt you would split the packet into CID and "C" (Ciphertext).  And
then you would (E'() is decrypt):
  CID . D = E'(C)

You would compare the plain text CID with the value in the encrypted
packet, logging an attack if they don't match.

You would also need to throw out "old" CIDs when they tried to initiate a
connection.  And also "old" packet sequence numbers.  To prevent replay
attacks.

This would let the packets arrive out of sequence, handle a missing packet
fine, and also ensure that two packets containing exactly the same data
did not have the same ciphertext (as they would have different sequence
numbers and CIDs).

> These are just some of my thoughts, please don't pin yourself by just
> looking at the "best" cipher... which is considered to be AES-CTR
> (block) by many people... as you see it has 120bits of overhead when
> used with GSM... (If the 33 bytes figure presented before is right)
> Cipher capabilities could be exchanged just like codec capabilities...
> and if a device (IAXy?) only happens to support plain AES... so be it,
> but please don't restrict the protocol to that :)

It would be nice, though, if the cipher something like AES, though, since
that would meet government requirements for encryption in the US.  It
might give us more users.  3DES would work - right now - but not in a few
years as 3DES is in the process of being phased out.  I do understand the
overhead issues, though.

I would say that I would have uses for this technology tomorrow if it was
cheap and affordable, had a well-engineered protocol (which mine probably
isn't - I just threw it out to show one way of trying to solve this
problem), etc.  I work with some organizations that really do need
encrypted voice but can't afford commercial encrypted telephones.  It
would also be a good way for me to get VoIP into those organizations.

-- 
Joel