Three-Party Symmetric Key Schemes
Jeffrey Walton
Does anyone have recommendations for a three party, two key symmetric
scheme for mobile clients?
In this problem domain, the parties are (1) a mobile client, (2) a
trusted LAN component, and (3) a perimeter/firewall component which
receives requests from the mobile client and routes to a trusted LAN
component.
A message sent by the mobile client has two distinct parts: (1) a
routing header which should be authenticated (but not necessarily
encrypted) by one component (perimeter/firewall) and (2) an encrypted/
authenticated payload for another component (trusted LAN).
The current implementation uses a pre-shared secret, so the current
code base favors a non-PKI solutions. I'm also interested in a scheme
where a shared secret is not stored on the perimeter/firewall
component.
Jeff
I've started the hunt with "Three-party Encrypted Key Exchange Without
Server Public-Keys" by Chun-Li Lin, Hung-Min Sun, Michael Steiner and
Tzonelih Hwang. But I'm going to need a couple of days to digest the
details.
Kristian Gjųsteen
>Does anyone have recommendations for a three party, two key symmetric
>scheme for mobile clients?
>
>In this problem domain, the parties are (1) a mobile client, (2) a
>trusted LAN component, and (3) a perimeter/firewall component which
>receives requests from the mobile client and routes to a trusted LAN
>component.
>
>A message sent by the mobile client has two distinct parts: (1) a
>routing header which should be authenticated (but not necessarily
>encrypted) by one component (perimeter/firewall) and (2) an encrypted/
>authenticated payload for another component (trusted LAN).
>
>The current implementation uses a pre-shared secret, so the current
>code base favors a non-PKI solutions.
What's wrong with the obvious solution? The client shares two keys, one
with the firewall and one with the trusted LAN component. He encrypts
the request with the second key, then authenticates the ciphertext with
the first key. The firewall verifies the MAC on the ciphertext, then
passes the ciphertext to the LAN component.
> I'm also interested in a scheme
>where a shared secret is not stored on the perimeter/firewall
>component.
If the client has a signing key, you can replace the outer MAC with a
signature?
--
kg
Jeffrey Walton
wrote:
> Jeffrey Walton <noloa...@gmail.com> wrote:
>
> >Does anyone have recommendations for a three party, two key symmetric
> >scheme for mobile clients?
>
> >In this problem domain, the parties are (1) a mobile client, (2) a
> >trusted LAN component, and (3) a perimeter/firewall component which
> >receives requests from the mobile client and routes to a trusted LAN
> >component.
>
> >A message sent by the mobile client has two distinct parts: (1) a
> >routing header which should be authenticated (but not necessarily
> >encrypted) by one component (perimeter/firewall) and (2) an encrypted/
> >authenticated payload for another component (trusted LAN).
>
> >The current implementation uses a pre-shared secret, so the current
> >code base favors a non-PKI solutions.
>
> What's wrong with the obvious solution? The client shares two keys, one
> with the firewall and one with the trusted LAN component.
since there should be no secrets on the perimeter/firewall component.
To satisy the "no secrets on perimeter/firewall", I think the only
solution is to have the perimeter/firewall get a {salt, MAC key} pair
from the trusted LAN component. Under this proposal, the perimeter/
firewall does not hold a secret (only the mobile client and trusted
LAN components hold the secret), and the perimeter/firewall can
forward the salt to the client so the client can arrive at the same
MAC key that is being used by the perimeter/firewall.
Here's what it looks like on paper (verification left out for
clarity):
Client Firewall Desktop
* == Need MAC Key ==> *
* == Client needs MAC Key ==> *
* <=== { Salt, MAC Key } ==== *
* <====== Salt ====== *
> He encrypts the request with the second key, then authenticates
> the ciphertext with the first key. The firewall verifies the MAC on
> the ciphertext, then passes the ciphertext to the LAN component.
That's pretty much it (classical AEAD: the firewall verifies the MAC
on the plain text routing information and the ciphertext for the
trusted LAN). And the perimeter/firewall cannot decrypt the data since
its under a different key.
> > I'm also interested in a scheme
> >where a shared secret is not stored on the perimeter/firewall
> >component.
>
> If the client has a signing key, you can replace the outer MAC
> with a signature?
No PKI/PKIX or trusted third parties, so no Kerberos. And I know that
PKI is not in the near future's roadmap.
I don't really want a 'bare bones' assymetric implementation for
signing though its very doable in CAPI, OpenSSL, and Crypto++. In
practice, I would still need a distinguished 'root' signing key.
Additionally, a signing key would double the number of secrets which
must be protected on the mobile client, which is not an easy task on
Windows CE and jail broken iPhones.
Conceptually, this is an easy problem. In practice, it's causing me a
lot of grief :/
Jeff
Kristian Gjųsteen
>Here's what it looks like on paper (verification left out for
>clarity):
>Client Firewall Desktop
> * == Need MAC Key ==> *
> * == Client needs MAC Key ==> *
> * <=== { Salt, MAC Key } ==== *
> * <====== Salt ====== *
You can allow the client to come up with the salt and deduce the MAC key
directly from the shared secret. That saves a round-trip Firewall-Client.
If you are worried about reuse of old MAC keys, you can include a
time stampt in the MAC key derivation (if the client has a reasonably
reliable clock).
C->F: salt, time, c=Enc(k1,x), MAC(KDF(k2,salt + time), salt+time+c)
F->D: salt, time
D->F: k3=KFD(k2, salt+time)
F->D: c
--
kg
Jeffrey Walton
wrote:
Kristian,
This seems like a common problem - client/server through a firewall
using a shared secret rather than PKI or trusted third parties (ie,
Kerberos). Client<->server is traditional, while client<->firewall
adds a wrinkle.
Is there no standard/proposed standard for this? I can envision
authenticated encryption all over again: take a secure cipher and a
secure MAC, and combine them in such a way that things are no longer
secure. I'd much rather use a system that has been vetted by the
security community.
Jeff
Kristian Gjųsteen
>This seems like a common problem - client/server through a firewall
>using a shared secret rather than PKI or trusted third parties (ie,
>Kerberos). Client<->server is traditional, while client<->firewall
>adds a wrinkle.
>
>Is there no standard/proposed standard for this? I can envision
>authenticated encryption all over again: take a secure cipher and a
>secure MAC, and combine them in such a way that things are no longer
>secure. I'd much rather use a system that has been vetted by the
>security community.
I know nothing about practical systems. Sorry.
But I fail to see the point of all this. Unless your crypto code is
shockingly bad, any ciphertext that didn't originate with a trusted
client should be discarded as invalid. So what's the point of doing
crypto on the firewall?
--
kg
Jeffrey Walton
wrote:
> Jeffrey Walton <noloa...@gmail.com> wrote:
>
> >This seems like a common problem - client/server through a firewall
> >using a shared secret rather than PKI or trusted third parties (ie,
> >Kerberos). Client<->server is traditional, while client<->firewall
> >adds a wrinkle.
>
> >Is there no standard/proposed standard for this? I can envision
> >authenticated encryption all over again: take a secure cipher and a
> >secure MAC, and combine them in such a way that things are no longer
> >secure. I'd much rather use a system that has been vetted by the
> >security community.
>
> But I fail to see the point of all this.
:)
> Unless your crypto code is shockingly bad, any ciphertext
> that didn't originate with a trusted client should be discarded
> as invalid.
Agreed. Traffic between the client and the desktop is authenc. This
begs the question, how does one reject at the firewall based on
authenticity, without allowing the firewall to decrypt the traffic
destined for the trusted LAN? And keep in mind that the system does
not use PKI (it uses a shared secret), and the firewall cannot store a
secret.
> So what's the point of doing crypto on the firewall?
Security postures: anything not authentic should be rejected at the
earliest opportunity. Its amazing how many Network/System
Administrator feathers get ruffled when you poke a hole in their
firewall and don't validate clients or traffic. I suppose its the
difference between theory and practice.
Shared secrets really muddies the water.
Jeff
Jeffrey Walton
wrote:
> Jeffrey Walton <noloa...@gmail.com> wrote:
>
> >Here's what it looks like on paper (verification left out for
> >clarity):
> >Client Firewall Desktop
> > * == Need MAC Key ==> *
> > * == Client needs MAC Key ==> *
> > * <=== { Salt, MAC Key } ==== *
> > * <====== Salt ====== *
>
> You can allow the client to come up with the salt and deduce the MAC key
> directly from the shared secret. That saves a round-trip Firewall-Client.
>
> If you are worried about reuse of old MAC keys, you can include a
> time stampt in the MAC key derivation (if the client has a reasonably
> reliable clock).
reasonable person would expect a device (without data plan) would
still be able to read the time from the network. We've had to work
around with a challenge/response.
> [SNIP]
Jeffrey Walton
The firewall component can reject anything with the EVIL bit set.