> On May 19, 2016, at 10:59 PM, Dave Tian <dave.jing.tian@xxxxxxxxx> wrote: > > > >> On May 19, 2016, at 8:06 PM, Keith Packard <keithp@xxxxxxxxxx> wrote: >> >> Oliver Neukum <oneukum@xxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
