Re: question on trust in chaoskey

[Oliver Neukum]

On Fri, 2016-05-20 at 17:13 -0700, Steve Calfee wrote:

> A clever attacker would provide a false USB key which is "almost"
> random. This would allow them to decrypt messages based on the false
> key, with nobody else knowing there was a vulnerability. An almost
> random number simplifies cracking.
> 
> It is easy to exactly duplicate all the descriptors and functionality
> in a false device. It could be easily done with a PIC, Arduino, or $9
> CHIP. Who could tell a key is false or genuine? The false device could
> do the same dance with public keys (or whatever secret handshake you
> setup).

To a point.There is no reason a key would ever have to go over the wire
unencrypted. You can get at it only by man-in-the-middle or if you get
at the hardware.
We can protect against sniffing and require authentification.

> If a user cannot be sure a key is genuine, and a false key can leak
> information, I don't see the point of anyone using such a USB device.

You will have to trust your hardware if you run a computer.
The questions of whether your hardware is indeed your hardware
and whether you can trust your hardware are distinct.
The former problem we can address.

Regards
Oliver


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: question on trust in chaoskey

[Steve Calfee]

Hi Keith,

On Thu, May 19, 2016 at 9:23 PM, Keith Packard  wrote:
> Dave Tian  writes:
>
>> I am personally in favor of a TPM-like solution, since we probably
>> couldn’t/shouldn’t disable the firmware update anyway,
>> and we really need a hardware root of trust (with a key embedded) in
>> the device, like the TPM in the host.
>
> I don't think we need a true TPM in the hardware; the device is
> read-only in normal operation with firmware upgrades requiring physical
> presence. So, supply the private key with the firmware and then erase it
> From the host once programmed. Once the programming jumper is removed,
> only physical access would be sufficient to extract the private key.
>
> Here's more information about the hardware:
>
> http://altusmetrum.org/ChaosKey/
>
> --

This is the first I have seen this gadget. The obvious use is with
encryption. The obvious problem is someone substituting a false USB
key for a genuine one. The classic "drop flash drives in a conference
lobby", and someone will use it and infect windows. A more
capitalistic attack for any system is someone offering a false USB
"key" for 10% less than anyone else. Any computer that allows any USB
device to be plugged in is at risk. That's why there is physical
protection for servers.

A clever attacker would provide a false USB key which is "almost"
random. This would allow them to decrypt messages based on the false
key, with nobody else knowing there was a vulnerability. An almost
random number simplifies cracking.

It is easy to exactly duplicate all the descriptors and functionality
in a false device. It could be easily done with a PIC, Arduino, or $9
CHIP. Who could tell a key is false or genuine? The false device could
do the same dance with public keys (or whatever secret handshake you
setup).

If a user cannot be sure a key is genuine, and a false key can leak
information, I don't see the point of anyone using such a USB device.

Regards, Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: question on trust in chaoskey

[Dave Tian]

> On May 19, 2016, at 10:59 PM, Dave Tian  wrote:
> 
> 
> 
>> On May 19, 2016, at 8:06 PM, Keith Packard  wrote:
>> 
>> Oliver Neukum  writes:
>> 
>>> I think we would need to use a form of public key cryptography
>>> in the same manner used to verify authorship of emails. The host
>>> would provide a nonce value that the device encrypts and returns.
>>> The host would verify the signature.
>> 
>> We could initially provision the devices with a unique key and provide
>> the public half on a piece of paper. You'd have to get that into the
>> kernel before the system needed any entropy though, and that seems hard.
>> 
>> -- 
>> -keith
> 
> Note that when we are talking about a nonce from host and a signature from 
> the device, we may potentially refer to TPM attestation.
> The TPM has its own unique private key embedded in the hardware to derive 
> other keys, such as the attestation keys,
> which can be used by the remote to verify the target’s firmware.
> I am personally in favor of a TPM-like solution, since we probably 
> couldn’t/shouldn’t disable the firmware update anyway,
> and we really need a hardware root of trust (with a key embedded) in the 
> device, like the TPM in the host.
> 
> Whether this key should be provisioned by the user or the manufacture is 
> another interesting story.
> Intel’s SGX[1] remote attestation is based on Intel’s EPID[2], which means if 
> the user want to make sure
> the desire enclave code is running on an Intel SGX-enabled CPU, he/she has to 
> ask Intel for help,
> since only Intel is able to verify if the attestation result was from a legit 
> CPU with SGX enabled.
> Apparently, it does not sound good. So people did not like the patch[3].
> So Intel is going to add a user-defined root-of-trust key in the CPU, which 
> can be set during the boot time[4].
> Now the solution seems more decent, since now we do not have to deal with 
> Intel anyway.
> BUT this does not mean Intel cannot do anything evil or users have a more 
> secure solution for CPU-based attestation.
> 
> Credit card A let users to pick up a password - however, users have to be 
> responsible for identity thefts.
> Credit card B does not have password at all - instead, users can dispute each 
> transaction.
> Which one would you use?
> 
> -daveti
> 
> 
> [1]https://software.intel.com/en-us/sgx
> [2]https://en.wikipedia.org/wiki/Enhanced_privacy_ID
> [3]http://www.spinics.net/lists/linux-driver-devel/msg83272.html

resend~

-daveti

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: question on trust in chaoskey

[Keith Packard]

Oliver Neukum  writes:

> I think we would need to use a form of public key cryptography
> in the same manner used to verify authorship of emails. The host
> would provide a nonce value that the device encrypts and returns.
> The host would verify the signature.

We could initially provision the devices with a unique key and provide
the public half on a piece of paper. You'd have to get that into the
kernel before the system needed any entropy though, and that seems hard.

-- 
-keith


signature.asc
Description: PGP signature

Re: question on trust in chaoskey

[Keith Packard]

Oliver Neukum  writes:

> Good point. The logical answer would be to not ship the key. That means
> that users would "format" their chaoskeys and get their private key into
> the kernel by an attribute or ioctl.

Now *there's* a good idea. Ship the firmware and firmware loader and
have the user generate a public/private pair when using the key for the
first time.

The firmware loader is a trivial C program at present, which takes an
ELF and can do variable substitution on it before dumping the resulting
binary into the device.

I'd have to ship the devices without boxing them; the enclosure I found
is pretty hard to open up to get at the reflashing connections.

-- 
-keith


signature.asc
Description: PGP signature

Re: question on trust in chaoskey

[Oliver Neukum]

On Thu, 2016-05-19 at 12:52 -0700, Keith Packard wrote:
> Oliver Neukum  writes:
> 
> > I think we would need to use a form of public key cryptography
> > in the same manner used to verify authorship of emails. The host
> > would provide a nonce value that the device encrypts and returns.
> > The host would verify the signature.
> 
> We're shipping the device containing the 'private key' all over the
> planet. How can you expect that to remain secure?

Good point. The logical answer would be to not ship the key. That means
that users would "format" their chaoskeys and get their private key into
the kernel by an attribute or ioctl.

Regards
Oliver


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: question on trust in chaoskey

[Keith Packard]

Oliver Neukum  writes:

> I think we would need to use a form of public key cryptography
> in the same manner used to verify authorship of emails. The host
> would provide a nonce value that the device encrypts and returns.
> The host would verify the signature.

We're shipping the device containing the 'private key' all over the
planet. How can you expect that to remain secure?

-- 
-keith


signature.asc
Description: PGP signature

Re: question on trust in chaoskey

[Oliver Neukum]

On Thu, 2016-05-19 at 14:12 -0400, Dave Tian wrote:


> > The Chaoskey device explicitly does not address physical
> > attacks. Assuming physical security makes things a lot easier, and
> > one
> > of the simplifications is that we can assume that any physical
> > device
> > connected to the machine which has the right USB IDs will be the
> > correct

Unfortunately we have seen a string of CVEs with forged device IDs.

> > device. I have taken the trouble to register a "real" USB ID for
> > this
> > device, so in theory, we shouldn't ever see an accidental collision.

The problem with that is "accidental".
> 
> 
> 1. Disable the firmware update from the manufacturer

That will not work if the attacker starts with his own gadget.

> 2. Sign the firmware - I have no idea where the signature is saved on
> the device and how the host retrieves the signature from the device

That won't work as the signature could be sniffed and forged.

> 3. USBTPM - a tpm embedded in the USB device which can measure the
> firmware, and the measurement can be retrieved by the host. (There
> seems no real implementation yet)

How do we know the claimed TPM is a genuine TPM?

I think we would need to use a form of public key cryptography
in the same manner used to verify authorship of emails. The host
would provide a nonce value that the device encrypts and returns.
The host would verify the signature.

Regards
Oliver



--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: question on trust in chaoskey

[Keith Packard]

Oliver Neukum  writes:

> Hi,
>
> I've been going through the drivers with an eye on security.
> And a question arose. How do we know that a device that claims
> to be a chaoskey is really a chaoskey?

A fine question, and one we've thought about extensively.

The Chaoskey device explicitly does not address physical
attacks. Assuming physical security makes things a lot easier, and one
of the simplifications is that we can assume that any physical device
connected to the machine which has the right USB IDs will be the correct
device. I have taken the trouble to register a "real" USB ID for this
device, so in theory, we shouldn't ever see an accidental collision.

-- 
-keith


signature.asc
Description: PGP signature