[LINK] Stolen Laptop [was Re: Consumer computer security]

Rick Welykochy rick at praxis.com.au
Mon Jan 29 02:04:22 AEDT 2007


Johann Kruse wrote:

> On 29/01/07, Rick Welykochy <rick at praxis.com.au> wrote:
>> Heh? AES encryption and decryption cost CPU cycles. Copying data from one
>> AES encrypted file to another will be measureably slower than the 
>> equivalent
>> non-enrypted copy. Microsoft would know this already. We Mac and Linux
>> users know this. Even if the AES functions are performed on the chip,
>> DMA to/from the chip will take extra time. Why the spin?
> 
> Personally I notice no difference in speed between two laptops of
> pretty much identical specs, one with Bitlocker and one without.

Try comparing duplicating a 1 GB file on an unencrypted volume and
doing the same on a Bitlocker-encrypted volume. I would be interested
in the CPU load for both operations.



> It won't destroy multi-boot capability -
> http://www.schneier.com/blog/archives/2006/05/bitlocker.html

Whew! Thanks for the Schneier reference. There is so much food for
thought on that page that I will defer for the time being. As for
multi-boot, it seems "possible" but tedious, and as yet unproven
"in the field", so to speak. Let's wait and see once Vista is released.
You know, it's a Microsoft spin thing. Be aware that Schneier does
report that once the master boot record is modified, Bitlocker
will prevent the machine from starting up. But, given the tenacity
of Linux-based and other boffins out there, the work-arounds
indicated by Schneier will of course be used, ie. Bitlocker
can be "reset" to make the multi-boot possible. But that leaves
me wondering if Bitlocker has then failed in its designed goal
and task.



> And new Macs come with TPM 1.2 so no problems there -
> http://www.osxbook.com/book/bonus/chapter10/tpm/

Well, the cat is out of the bag, if the above article is correct:

"The TPM is not a cryptographic accelerator. It is not meant to aid in bulk
  encryption. Moreover, the specification does not contain any cryptographic
  throughput requirements."

Sounds like AES cryptography is done in software. As I said, we on
Macs and Linux already know the time and space requirements of AES in
software.



>> Howard Lowndes wrote:
>>
>>  >> "BitLocker leverages the 1.2 specification TPM chip"
>>  > Has anyone seen one of these on a mobo yet?
>>  > Or are they doing the right thing by avoiding them.
> 
> Yes, I have TPM 1.2 in 2 laptops and 1 desktop, and my mate has it in 
> his Mac.

I have the hard drive protection I need sans the TPM chip. What
advantage doe the on-board chip offer?


> 
> And I guess this could in some ways be (heaven forbid) a
> forward-looking thing.  Once upon a time computers didn't have maths
> co-processors, sound cards, or USB ports built-in - but they seem to
> be pretty common now.

I really don't understand what the TPM chip offers us computer
users. We don't find that "tamper-resistance" in hardware is really
a problem. I think that the big players in the content provision
markets might. The real problem right now involves ineffective
and non-existent security on millions and millions of PCs connected
to our Internet. The real problem with online computing concerns
social engineering scams, spam, DDoS attacks, extortion and money
laundering to mention just a few.

Until the very real and serious problems that already exist on
platforms such as the various Windows systems are addressed (as
but one example) I find it vacuous, diversionary and self-serving
for corporations to focus on Yet Another Security Panacea.

Can you explain to Link why we would want trusted computing (TC), Johann?
And what does TC have to do with securing your hard drive data?

I ask since I am doing that just fine sans any TC hardware or software
at the moment, and I for one will not be sold a trojan horse at the
hidden bequest of content providers, neither now or in the future.

cheers
rickw


-- 
_________________________________
Rick Welykochy || Praxis Services

If you think good architecture is expensive, try bad architecture.
      -- Brian Foote and Joseph Yoder



More information about the Link mailing list