Subject: Re: [http-auth] Reboot: Protecting users and institutions from victimization by eavesdroppers & cyber criminals

From: Jim McAlear <[email-masked]>
Date: Sun, 2 Dec 2012 14:31:56 -0800 (PST)

Hi Nico -
 
Thanks for this. I've long worked in the sensible area of protocols, and it's just in the past few years that I've been exposed to the cyber-security arena - and I have to admit that I'm generally horrified by the sheer morass of complexity involved there. So of course, to proceed pragmatically, protocol designers need to assume local security - even though this isn't a good assumption in reality - because without such an assumption, protocol designers wouldn't be able to get on with the job. But in the fight between attackers and defenders, cyber security experts are nowhere near acheiving the level of success that protocol designers have; so unless they start to contemplate some revolutionary new approaches, then the trends of massive, industrial scale victimization will continue for a long time. Now since protocols designers are so far ahead in acheiving their objectives, perhaps it is time for local security experts to learn a thing or two from us. 
 
What I would like to submit is a first sketch of an authentication protocol, that could be implemented in a unit of compartmentalized circuitry that runs independent of the host's operating system, that will ensure that an authentication transaction can be completed securely. The authentication procedure would be designed in such a way, that it would be seamlessly operable by user-agents/browsers, regardless of whether the local hardware supports a compartmentalized authentication capablity or not. Furthermore, it will not require any more fundamental capability than that which is already contained within modern browsers (certificate checking, key-exchange, encryption etc.). But if the hardware were to have a secure compartment, then this small unit could implement the authentication procedure on its own (perhaps as a state machine, perhaps as an embedded capability) - in a way that thwarts any malware access or tampering with the authentication.
 With such a secure compartmentalized transaction capability, we could reliably keep key credentials (passwords, credit card numbers and more) out of the reach of malware, and thwart all the easy-money silient victimization that happens as well as wider identity theft crimes.
 
With such a flexibility built in, we could well see military, government and financial sectors begin to adopt the compartmentalization approach within their operations, and then a mass-market roll-out could quickly follow. It's clear that the local security people need help and require novel new approaches to acheive our shared objectives. Would it hurt for me to submit a quick sketch of how the protocol would operate? I'll prepare a sketch over the next few days - it will apply to the user-agent/browser side first; I'll cover the server end shortly thereafter. Protocol designers have already done a lot to prevent victimization of users - would it hurt to consider one further step forward that could solidify the acheivement in a way that fills the gaping hole that local security experts have left open?
 
Questions/comments/next steps?
 
- Jim McAlear
Ottawa, Canada

________________________________
 From: Nico Williams <[email-masked]>
To: Jim McAlear <[email-masked]> 
Cc: "[email-masked]" <[email-masked]> 
Sent: Friday, November 30, 2012 5:12:21 PM
Subject: Re: [http-auth] Reboot: Protecting users and institutions from victimization by eavesdroppers & cyber criminals
  
On Wed, Nov 28, 2012 at 7:03 PM, Jim McAlear <[email-masked]> wrote:
> Time after time, through efforts like: SSH, HTTPS and IPSEC and much more, the IETF has tried to protect users and institutions from victimization by network eavesdroppers and man-in-the-middle operators. But cybercriminals easily defeat our goals by implanting malware on servers and PCs – resulting in victimization on a massive, industrial scale. The aim of this contribution is to show that a solution to our longstanding goal is potentially within reach – and that if we carefully craft a new authentication procedure that is flexible enough to handle some novel hardware configurations, then we can finally provide users and institutions with our long-desired protection against victimization by cyber criminals – at least in the important areas of protecting critical credentials and transactions (safe e-commerce). The attachment outlines the solution at a high level.
>
> Do you agree that this is a laudable goal? Questions/comments/next steps?

Local security is something that our protocols all assume: they extend
local security to the network, not the other way around.  This is true
of *all* of our security protocols: IPsec, SSHv2, TLS, Kerberos, SASL,
...  We work on protocols here, not so much local security, but we do
try to make our protocols easier to protect from local compromises.
For example, Kerberos has temporary credentials the compromise of
which is easier to recover from than the compromise of long-term
credentials; PKIX is amenable to smartcard and other token solutions.
This is all very nice, but sadly, that's about as far as we can go
with network protocols, maybe we can go as far as NEA (an attempt to
authenticate end-point state), combined with TPMs and OSes that are
amenable to secure bootstrapping with TPMs.

I'd like to separate what features we want in protocols to improve
security in the face of local compromises (namely, we want temporary
credentials and/or suitability for smartcards) from what we want done
for local security.  The two are very different fields of work that
barely intersect, and mostly only because we must assume that local
security will be compromised from time to time.

(Yes, I know, I mostly only dealt with client-side local security above.)

Nico
--

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 03 Dec 2012 07:20:43 +0200

Hi Jim,

to be more widely applicable, I would suggest that your proposal should 
cover TPM assertions, in addition to the more exotic 
compartmentalization that you suggest in your slide deck. TPM after all 
is widely available, and is (very slowly) gaining some software support.

I realize that TPM can only authenticate the machine, while your 
proposal can also authenticate the user.

Thanks,
	Yaron

On 12/03/2012 12:31 AM, Jim McAlear wrote:
> Hi Nico -
> Thanks for this. I've long worked in the sensible area of protocols, and
> it's just in the past few years that I've been exposed to the
> cyber-security arena - and I have to admit that I'm generally horrified
> by the sheer morass of complexity involved there. So of course, to
> proceed pragmatically, protocol designers need to assume local security
> - even though this isn't a good assumption in reality - because without
> such an assumption, protocol designers wouldn't be able to get on with
> the job. But in the fight between attackers and defenders, cyber
> security experts are nowhere near acheiving the level of success that
> protocol designers have; so unless they start to contemplate some
> revolutionary new approaches, then the trends of massive, industrial
> scale victimization will continue for a long time. Now since protocols
> designers are so far ahead in acheiving their objectives, perhaps it is
> time for local security experts to learn a thing or two from us.
> What I would like to submit is a first sketch of an
> authentication protocol, that could be implemented in a unit of
> compartmentalized circuitry that runs independent of the host's
> operating system, that will ensure that an authentication transaction
> can be completed securely. The authentication procedure would be
> designed in such a way, that it would be seamlessly operable by
> user-agents/browsers, regardless of whether the local hardware supports
> a compartmentalized authentication capablity or not. Furthermore, it
> will not require any more fundamental capability than that which is
> already contained within modern browsers (certificate checking,
> key-exchange, encryption etc.). But if the hardware were to have a
> secure compartment, then this small unit could implement the
> authentication procedure on its own (perhaps as a state machine, perhaps
> as an embedded capability) - in a way that thwarts any malware access or
> tampering with the authentication. With such a secure compartmentalized
> transaction capability, we could reliably keep key credentials
> (passwords, credit card numbers and more) out of the reach of malware,
> and thwart all the easy-money silient victimization that happens as well
> as wider identity theft crimes.
> With such a flexibility built in, we could well see military, government
> and financial sectors begin to adopt the compartmentalization approach
> within their operations, and then a mass-market roll-out could quickly
> follow. It's clear that the local security people need help and require
> novel new approaches to acheive our shared objectives. Would it hurt
> for me to submit a quick sketch of how the protocol would operate? I'll
> prepare a sketch over the next few days - it will apply to the
> user-agent/browser side first; I'll cover the server end shortly
> thereafter. Protocol designers have already done a lot to prevent
> victimization of users - would it hurt to consider one further step
> forward that could solidify the acheivement in a way that fills the
> gaping hole that local security experts have left open?
> *From:* Nico Williams <[email-masked]>
> *To:* Jim McAlear <[email-masked]>
> *Cc:* "[email-masked]" <[email-masked]>
> *Sent:* Friday, November 30, 2012 5:12:21 PM
> *Subject:* Re: [http-auth] Reboot: Protecting users and institutions
> from victimization by eavesdroppers & cyber criminals
>
> On Wed, Nov 28, 2012 at 7:03 PM, Jim McAlear <[email-masked]
> <mailto:[email-masked]>> wrote:
>  > Time after time, through efforts like: SSH, HTTPS and IPSEC and much
> more, the IETF has tried to protect users and institutions from
> victimization by network eavesdroppers and man-in-the-middle operators.
> But cybercriminals easily defeat our goals by implanting malware on
> servers and PCs – resulting in victimization on a massive, industrial
> scale. The aim of this contribution is to show that a solution to our
> longstanding goal is potentially within reach – and that if we carefully
> craft a new authentication procedure that is flexible enough to handle
> some novel hardware configurations, then we can finally provide users
> and institutions with our long-desired protection against victimization
> by cyber criminals – at least in the important areas of protecting
> critical credentials and transactions (safe e-commerce). The attachment
> outlines the solution at a high level.
>  >
> _______________________________________________
> http-auth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-auth
>

---

From: Nico Williams <[email-masked]>
Date: Mon, 3 Dec 2012 11:35:18 -0600

On Sun, Dec 2, 2012 at 4:31 PM, Jim McAlear <[email-masked]> wrote:
> What I would like to submit is a first sketch of an authentication protocol,
> that could be implemented in a unit of compartmentalized circuitry that runs
> independent of the host's operating system, that will ensure that an
> authentication transaction can be completed securely. The authentication
> [...]

In other words, you want an HSM/smartcard ("compartmentalized
circuitry that runs independent of the host's OS") on the client side.

> Questions/comments/next steps?

We all want an HSM on the client side.  With smartphones we're at
least getting to where users carry devices with them; before the
password was king.  But even now password are still the fallback plan
and will continue to be for the foreseeable future.  And as for HSMs,
we're still not close to where we can require them, or even count on
more than a tiny proportion of the population having them.  I wish it
were not so.

But there's a few problems:

 - users don't always have such devices with them (indeed, they almost
never do, though this could change if they were built into smartphones
and tablets)

 - local security still matters: the user still interacts with the HSM
through the local OS, and it has to be so; if local security is
compromised, then the attacker can still use the HSM

 - PIN entry doesn't help enough: if it happens too often the user
will be very annoyed and the technology might fail, but if it doesn't
happen often enough then attackers can use the HSM without the user's
knowledge (at least there's auditing...)

 - PIN entry really also needs to be accompanied by a display of what
credentials will be used and what for -- without this the user is left
only to correlate the timing of a PIN entry requirement with the
timing of user actions

 - PIN entry through the host is susceptible to theft

 - PIN entry external to the host requires a PIN entry pad, something
that is not going to happen in smartphones nor tablets; see above
comment about PIN entry UI

 - the HSM has to be in smartphones/tablets -- users don't want to
carry N > 1 (or maybe 2) devices

 - device loss (theft, loss, accidental destruction) must be covered,
but in that case the only thing that works is authenticating the user
without the help of any devices, which kinda means: passwords and/or
little pieces of paper claiming to have been issued by some government

I'm not trying to be a downer here.  Local security will always
matter.  We have to do better in the realm of local security, much,
much better.  There's no avoiding it.

In the meantime we have other pressing problems that canbe addressed
more easily/quickly.

Quick question: do we have statistics on MITB attacks?

Nico
--