[4057] in cryptography@c2.net mail archive
Re: Cryptoprocessors
daemon@ATHENA.MIT.EDU (Markus Kuhn)
Sun Jan 24 20:54:19 1999
To: cryptography@c2.net
Cc: decius@bleeding.edge.net
In-reply-to: Your message of "Fri, 22 Jan 1999 14:41:49 CST."
<199901222041.OAA15937@bleeding.edge.net>
Date: Sat, 23 Jan 1999 12:30:23 +0000
From: Markus Kuhn <Markus.Kuhn@cl.cam.ac.uk>
decius@bleeding.edge.net wrote on 1999-01-22 20:41 UTC:
> I've been wondering for years why the ideas presented in Markus
> Kuhn's paper haven't been pursued by Intel or a competitor.
Actually, some people working for these CPU makers have read my paper
already some time ago and have confirmed to me that there is a
significant overlap between the ideas in my paper and the security
extensions that they have already in the queue for planned processors.
The details vary of course: For instance in my paper, the threat model
is a well-equipped attacker with a good logic analyzer connected to the
motherboard and therefore the encryption has to be done directly on the
L1 cache. I hear that the industry considers also a near-term variant
for a somewhat weaker threat model, where the risk is more someone using
only CPU executed software to read the protected binary (as opposed to
board eavesdropping hardware). In that case, it could be sufficient to
do the cryptography at the paging level and not per cache-line, which
makes the hardware simpler. The general concept of CPU encryption for
hardware-ensured access control to the software itself is by no means
something you will have to wait for a long time.
I don't claim that the concept that I described in
http://www.cl.cam.ac.uk/~mgk25/trustno1.pdf
is already complete: For instance you could add direct CPU<->CPU license
transfers without the involvement of the vendor. One of the problems
that I have not yet entirely understood is for example: How do we handle
shared libraries efficiently and securely in a TrustNo1 processor with
encrypted segments.
> One potential problem with such a system is that it allows
> software vendors to include malicious code in their products with little
> or no chance of being caught.
I don't think this is a severe additional threat. Decompiling software
is a rather difficult and not widely practiced art. Practically no
reverse-engineering of large binary applications (such as Internet
Explorer) is going on at the moment, it would just be orders of
magnitude too tedious. So we do not lose too much compared to today.
I think that having something like the TrustNo1 processor widely
implemented has a number of advantages and no real disadvantage:
- People might even less trust binary-only distributions and will
therefore get more interested in
a) open source software (which allows easier independent
security evaluation)
b) operating systems with mandatory access control mechanisms
and multi-level capability control (which make the
implementation of Trojan horse software considerably more
difficult, but are so far unfortunately only used in
military applications)
- Copyright infringement will be reduced, which will strengthen
especially the position of smaller software companies that
are much more exposed to the threats of piracy than huge players
like Microsoft with a lot of control power. In addition, the
old shareware idea of distributing online products at a
very low cost (less than 5-10 euros per product) might finally
become viable and might lead to a highly diverse and flexible small
enterprise software industry that is really competing for nothing
but customer satisfaction. I consider this to be a good idea, being
both a software customer and developer.
Steve wrote on 1999-01-23 03:01 UTC:
> That could be the silver bullet that kills the otherwise unstoppable
> spread of non-GAK crypto.
I don't think so. The free market would not accept processors with
advanced software protection mechanisms that are not backwards
compatible to the existing non-encrypted products. In addition, the open
source and freeware community, which is completely unaffected by
encrypted software upload mechanisms, has already reached sufficient
critical mass in the PC world. Bus-encryption processors that only
accept authenticated software are not viable on the PC market, but they
might indeed have a place in embedded niche applications such as game
consoles and set-top boxes.
Markus
--
Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK
Email: mkuhn at acm.org, WWW: <http://www.cl.cam.ac.uk/~mgk25/>
