On Thu, Aug 08, 2002 at 09:15:33PM -0700, Seth David Schoen wrote:
Back in the Clipper days [...] how do we know that this
tamper-resistant chip produced by Mykotronix even implements the
Clipper spec correctly?.
The picture is related but has some extra wrinkles with the
TCPA/Palladium attestable donglization of CPUs.
- It is always the case that targetted people can have hardware
attacks perpetrated against them. (Keyboard sniffers placed during
court authorised break-in as FBI has used in mob case of PGP using
Mafiosa [1]).
- In the clipper case people didn't need to worry much if the clipper
chip had malicious deviations from spec, because Clipper had an openly
stated explicit purpose to implement a government backdoor -- there's
no need for NSA to backdoor the explicit backdoor.
But in the TCPA/Palladium case however the hardware tampering risk you
identify is as you say relevant:
- It's difficult for the user to verify hardware.
- Also: it wouldn't be that hard to manufacture plausibly deniable
implementation mistakes that could equate to a backdoor -- eg the
random number generators used to generate the TPM/SCP private device
keys.
However, beyond that there is an even softer target for would-be
backdoorers:
- the TCPA/Palladium's hardware manufacturers endoresment CA keys.
these are the keys to the virtual kingdom formed -- the virtual
kingdom by the closed space within which attested applications and
software agents run.
So specifically let's look at the questions arising:
1. What could a hostile entity(*) do with a copy of a selection of
hardware manufacturer endorsement CA private keys?
( (*) where the hostile entity candidates would be for example be
secret service agencies, law enforcement or homeland security
agencies in western countries, RIAA/MPAA in pursuit of their quest to
exercise their desire to jam and DoS peer-to-peer file sharing
networks, the Chinese government, Taiwanese government (they may lots
of equipment right) and so on).
a. Who needs to worry -- who will be targetted?
Who needs to worry about this depends on how overt third-party
ownership of these keys is, and hence the pool of people who would
likely be targetted.
If it's very covert, it would only be used plausibly deniably and only
for Nat Sec / Homeland Security purposes. It if becomse overt over
time -- a publicly acknowledged, but supposedly court controlled
affair like Clipper, or even more widely desired by a wide-range of
entities for example: keys made available to RIAA / MPAA so they can
do the hacking they have been pushing for -- well then we all need to
worry.
To analyse the answer to question 1, we first need to think about
question 2:
2. What kinds of TCPA/Palladium integrity depending trusted
applications are likely to be built?
Given the powerful (though balance of control changing) new remotely
attestable security features provided by TCPA/Palladium, all kinds of
remote services become possible, for example (though all to the extent
of hardware tamper-resistance and belief that your attacker doesn't
have access to a hardware endorsement CA private key):
- general Application Service Providers (ASPs) that you don't have to
trust to read your data
- less traceable peer-to-peer applications
- DRM applications that make a general purpose computer secure against
BORA (Break Once Run Anywhere), though of course not secure against
ROCA (Rip Once Copy Everywhere) -- which will surely continue to
happen with ripping shifting to hardware hackers.
- general purpose unreadable sandboxes to run general purpose
CPU-for-rent computing farms for hire, where the sender knows you
can't read his code, you can't read his input data, or his output
data, or tamper with the computation.
- file-sharing while robustly hiding knowledge and traceability of
content even to the node serving it -- previously research question,
now easy coding problem with efficient
- anonymous remailers where you have more assurance that a given node
is not logging and analysing the traffic being mixed by it
But of course all of these distributed applications, positive and
negative (depending on your view point), are limited in their
assurance of their non-cryptographically assured aspects:
- to the tamper resistance of the device
- to the extent of the users confidence that an entity hostile to them
doesn't have the endorsement CA's private key for the respective
remote servers implementing the network application they are relying
on
and a follow-on question to question 2:
3. Will any software companies still aim for cryptographic assurance?
(cryptographic assurance means you don't need to trust someone not to
reverse engineer the application -- ie you can't read the data because
it is encrypted with a key derived from a password that is only stored
in the users head).
The extended platform allows you to build new classes of applications
which aren't currently buildable to cryptographic levels of
