Re: Intel's encryption in Eaglelake or should we trust hardware encryption?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jan 10, 2008 at 02:45:40PM +0100, Clemens Fruhwirth wrote:
> The following link has a presentation about the upcoming 'technology'
> in the Intel chipset Eaglelake. First of all, this sounds really
> interesting in terms of performance. It basically talks about
> embedding hardware encryption within the hard disk controller on the
> north bridge.
> 
> http://inteldeveloperforum.com.edgesuite.net/fall_2007/d2/SCIS003/f.htm
> 
> I apologize for posting this link. It will only play in Internet
> Explorer browsers and -- even worse -- for me, only after installing
> Windows Media Player 10. Feel free to flame Intel therefore.
> 
> You can safely focus on minute 24. The rest of the presentation is
> about management stuff and hyping some 3rd party vendor's product
> (not interesting at all).

IE-only => I will not look at it.
 
> However, it got me thinking whether I trust these solution. I
> inherently feel more secure when using software I wrote and compiled
> myself than using hardware. But what's the difference when the
> bitstream that tumbles out at both ends -- AES hardware and AES
> software -- are identical?

Ciphers in hardware are generally not a problem, except for local 
attacks.

> I found for me that the argument that makes me uneasy is that hardware
> encryption is so much more specialized in use than a general purpose
> CPU. The intentions are so much more clear when using the API. The key
> when loaded into the chipset really stands out and capturing it is so
> much more easy; capturing can mean by sniffing the bus (which is
> technically almost impossible for attackers with limited budget, also
> the system has to be online, and you have to type in key material
> while the attack is in progress). 

One problem is that the key-material may be visible to an other
process. IT has to be prossible to really remove the key during 
task-switch (which may take a lot of effort and may not be done 
for this very reason).
 
> What I'm more worried about is intentionally backdoored crypto
> hardware. Are we really so naive to believe that -- given the series
> of illegal (no search warrants, no respective law) cooperations of
> large business entities with the NSA[1] -- these guys will allow it to
> happen that Intel starts (significant market share) to deploy
> industrial strength encryption technology worldwide? Even if I'm not
> that paranoid that answer wholehearted "No" to this question, I'm still
> suspicious.

I am sure the enemies of freedom sure would like to have backdooors 
in everything. But having a backdoor in a block cipher in hardware
is only possible if the cipher itself has the backdoor. AES is a
1:1 mapping and cannot have a backkdoor that allways works. It 
could (theoretically) have one that compresses the data and then 
embeds something in the bits gained. However the AES structure
does not seem to do that.

> The same task for backdooring CPUs is almost impossible. It is
> inherently hard to semantically decipher the stream of instructions by
> static/syntactic analysis. Tell apart the set of instruction that sets
> up an AES key from the instructions that does context switching,
> device management or displays the toolbar of your email client can't
> be done, hence no backdooring is possible, here. As said, for special
> purpose hardware it's all different. The API is clearly sketched out
> and tampering with the crypto chip itself would be the way to go if
> you are a large intelligence agency and your business consists of
> mass monitoring.

Same limits here. The "flow of instruction" complexity is not really 
any protection, IMO. Cipher operations should be recognizable.
And you can just use every 128 bit value observed as trial key.

> I hope the community can produce good counter arguments to my
> reasoning above. I hope so because, otherwise I should start to push
> for performance of dm-crypt even without hardware assistance.

What about  key generation? That one is pretty easy to backdoor. Is 
there any key generation or otherwise randomness generation or
processing in this chip?

Arno
-- 
Arno Wagner, Dipl. Inform., CISSP --- CSG, ETH Zurich, arno@xxxxxxxxxxx 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier 

---------------------------------------------------------------------
dm-crypt mailing list - http://www.saout.de/misc/dm-crypt/
To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx
For additional commands, e-mail: dm-crypt-help@xxxxxxxx


[Index of Archives]     [Device Mapper Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux