Re: Protecting Encryption Algorithms
From: NYC (name_at_company.com)
Date: 01/30/04
- Next message: Johan Lindh: "Re: Comments wanted on an authentication protocol"
- Previous message: Tarapia Tapioco: "Re: LEN SASSAMAN: WHERE DID YOU LEARN HOW TO LIE WITH SUCH A BALD FACE"
- In reply to: Jeff: "Re: Protecting Encryption Algorithms"
- Next in thread: jcduque: "Re: Protecting Encryption Algorithms"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Fri, 30 Jan 2004 20:23:52 +0100
Jeff wrote:
> That was an attempt at HUMOUR (an obscure concept these days). Not
> infrequently, I've seen posts starting with something akin to "I'm not a
> lawyer, nor do I play one on TV". I tried a variation on the theme.
> Attempts at HUMOUR do not always succeed.
Sorry, I just didn't see why it was funny.
> Assuming it really is "new technology". It really sounds like a repackaging
> of other schemes (that didn't work).
I agree many schemes like this has failed. But that doesn't mean that
any scheme, with the same objective, will.
> No, I do understand. The OP wants to protect his program. The sealed-chip
> example would have the program encrypted on disk and would decrypt it before
> sending the unencrypted code to the CPU. Since the CPU deals with plaintext
> (where plaintext is the OP's executable code), and since I as root have
> total control of the CPU, I expect I can get the plaintext. It is
> conceivable that the sealed-chip could be tightly coupled with the CPU to
> prevent root from gaining access to the plaintext, although since I have
> direct access to the hardware I may be able to do an end run around that
> roadblock.
In the case of the 4758 adapter, the CPU is inside the sealed package
(along with memory, key storage etc.), meaning that even though it is
fed plaintext code, you can't see it, because as soon as you try to
break the sealed package, the data disappears.
As I clearly stated, this is as a possible attack on the
NGSCB/LaGrande/SEM system. It is not secure against all possible
hardware attacks. But it is technically possible to extend the scheme in
the future, so that it will become more like a 4758.
> Not necessarily. Will the protected software work on machines without the
> protection scheme? If not, then users needing that software, or the
> upgrade, will need to buy a new machine (whose cost has only been increased
> by $20 for the additional hardware). If a competing program that doesn't
> use the new hardware is available at a reasonable price and doesn't require
> any hardware upgrade, consumers may well go with the competitor rather than
> an expensive hardware upgrade.
Computer doesn't last forever, and if the tech is put into the computers
sold now (but not necessaryily used for DRM) sooner or later everyone
will have it, making software distribution this way possible. In any
case, the discussion was about the general (im)possibility of being able
to hide an algorithm from its user.
>>As for software distribution, if done right, it would be transparent to
>>the user. I don't see why it shold be any more difficult than current
>>software distribution over the web. Could you elaborate on the
>
> difficulties?
>
> I'm not necessarily thinking about software distribution over the web.
> Rather, I'm thinking about software installation within the context of a
> corporate network.
The software company could make a program that runs in the secure
environment on a corporate server. This program has a clear-text version
of the software that they want to protect, and can distribute it under
encryption to a certain number of clients on the network (just as the
company could itself from a website). In other words, the distribution
simply gets delegated to a company server. The good thing is that the
company server can be trusted with this task, since the company making
the software can be sure (unless the system is broken) that the server
is going to respect license restrictions (for instance, restrictions on
the number of clients it is allowed to hand copies) and that it won't
spit out the software in unencrypted form. The server could keep track
of the identities of the client computers in a database, so that they
can get a re-install whenever they need it, and in that case, the server
wouldn't count that as an extra license. The software is obviously
transferred in encrypted form to the company server as well, so that it
will only be available in plain-text inside the secret module(s).
> Okay. The OP sounded more along the lines of needing to do so rather than
> just an intellectual discussion.
Right, however in the discussion of the OP's question, some remarks were
made about the general impossibility of doing something like this. My
point is that while it is infeasible right now, it wouldn't require too
many hardware modifications to the PC before this does become a possibility.
- Next message: Johan Lindh: "Re: Comments wanted on an authentication protocol"
- Previous message: Tarapia Tapioco: "Re: LEN SASSAMAN: WHERE DID YOU LEARN HOW TO LIE WITH SUCH A BALD FACE"
- In reply to: Jeff: "Re: Protecting Encryption Algorithms"
- Next in thread: jcduque: "Re: Protecting Encryption Algorithms"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
