[cryptography] Application Layer Encryption Protocols Tuned for Cellular?

ianG iang at iang.org
Mon Nov 5 16:52:08 EST 2012


On 4/11/12 10:17 AM, Jeffrey Walton wrote:
> On Sat, Nov 3, 2012 at 6:25 PM, ianG <iang at iang.org> wrote:
>> On 1/11/12 10:55 AM, Peter Gutmann wrote:
>>>
>>> Jeffrey Walton <noloader at gmail.com> writes:
>>>
>>>> Is anyone aware of of application layer encryption protocols with session
>>>> management tuned for use on cellular networks?
>>>>
>>>> [...]
>>>
>>>
>>>   From that description your problem isn't at the encryption-protocol level
>>> at
>>> all, you need a reliable transport mechanism for cellular networks,
>>
>> Sounds like.  The short answer is:  use UDP datagrams [1].
>>
>> This is a good answer because in doing so you will be forced to construct
>> your own reliable transport mechanisms over UDP, as and when you discover
>> the various failure cases.  (e.g., a lesson of discovery, fun!)
>>
>> It's not such a good answer if your team is used to ignoring all those
>> problems by using TCP and thinking they're done 'n dusted.  It's not a good
>> answer if you are thinking you can do some quick tweaks to an existing app -
>> as in practice it probably relies on TCP in which case the entire design is
>> poisoned with the assumptions therein (more below).
> My observation after self-reflection: TCP/IP is so ingrained, I was
> subconsciously depending upon the "connection oriented, reliableness"
> it offered - it was a session management crutch (albeit an "untrusted
> session" management crutch).
>
>>> something
>>> that's totally independent of what crypto you're using.  Then you run your
>>> favourite crypto over that.
>>
>> I'm not convinced of that.  This whole concept of 'layering' as a useful
>> simplification kind of took a wrong turn around the late 1980s with ISO's 7
>> layer model.  Although a useful abstraction, it led people into thinking
>> that if they built protocols for each layer then they could plug them in
>> together and everything would be fine!  Science has triumphed again!  Let's
>> mandate a set of protocols in each layer!
> I'm not convinced either. In the past, I used to feel that way, but
> I'm reconciling it now.
>
> I recently had the epiphany: the crypto layer must have some
> rudimentary session management stuff. Session management is clearly
> outside the realm of crypto. Session management is usually handled
> higher in the stack.


Yes, exactly.  The crypto provides the basis for the session management.

(I'm not sure why you say it is outside realm of crypto, I'm wondering 
if this might just be another customary assumption that has to be 
unlearned.)

> Rudimentary session management is required for fast recovery in the
> cellular environment. Previously, the implied session was the tuple
> {Client IP, Client Port, Server IP, Sever Port}. Because of TCP/IP
> tricks being played by handset manufacturers, carriers, and OS
> provided connection managers, it is no longer reliable. My apologies
> if I incorrectly fingered someone here.
>
> I think the on-wire and over-the-air message format needs to be changed to:
>
>      {Session ID, IV, Encrypted Data, Auth Tag}
>
> I clearly need an authenticated encryption mode with AAD. I'm
> researching the implications of a plain text Session ID.
> Heuristically, its no worse then the previous plain text {Client IP,
> Client Port, Server IP, Sever Port}.


Yep, that's pretty much what we did [1]:

    {Session ID, Encrypted Data, Auth Tag}

That which was traditionally an IV became split between some additional 
secret session data and a unique header as first block of plaintext packet.

Then, to initiate the session, one needs at the application layer 
something like a public/private key pair [2] which CodesInChaos also 
hinted at.  A single signed-encrypted-request-response sets up a shared 
secret for the session:

    {client-encrypt-key, client-IV, client-HMAC-tag,
     server-encrypt-key, server-IV, server-HMAC-tag}

[3].

> By having an explicit Session ID, it does not matter what UDP socket
> sends the message. I believe it allows for the fast recovery I am
> seeking.

Yep!  Or, it makes the system agnostic to sender-IP-address.  If that's 
what you call recovery, that's fine, I'd say it is just casting off a 
troublesome and unneeded assumption.


iang




[1]  We being Zooko and I, it being SDP1.  Documented to some extent at
http://webfunds.org/guide/sdp/
but apparently offline atm.  Google caches at
http://webcache.googleusercontent.com/search?q=cache:http://webfunds.org/guide/sdp/


[2]  C.f. John Day's 'slate' slides:  the public key can be seen as the 
identifier of the application, or 'application name.'  The private key 
can perform the crypto task of the authentication, for the IPC 
Authentication Protocol (IAP).


[3] Notes:  On the plus side, the session can be set up with only 2 
messages, one there, one back.  Consequently it is a lot faster and more 
reliable than that old SSL-over-TCP thing, which seems to revel in setup 
costs.

This approach also assumes multiple & easy sessions, being lightweight 
and promiscuous.  Which contrasts with your "only one session" 
requirement.  I'm not sure why you would want that, tho, as 
single-sessions seems to be a bandaid put over a broken model, not a 
high level requirement, with value in and of itself.

On the negative side, this entire approach will cause so much change in 
your code & application you'll likely be looking at a complete re-write. 
  At least, that's what happened to me.



More information about the cryptography mailing list