I seriously doubt anyone is saying you can crack AES
*WITHOUT* access to the
keys or a serious flaw in the implementation there of.
This article is about a
flaw where the keys are in RAM in the clear. Flushing
the keys when the system
goes into a locked or suspend state (while halting
processes that need access to
the encrypted data) and forcing the keys to be
re-entered externally on resume
would remove this vulnerability completely.
Hardware *is* the solution if you understand the flaws
of using general purpose
computers to run encryption software vs. dedicated
hardware doing it. Then
factor in as you said, an external factor like a token
or certificate that is
separate from the PC. Without RAM to be accessed,
there locally is no key to be
found by forensics. As to if someone can get to the
other component needed to
decrypt is another discussion completely and moot if
that component can be
destroyed.
A completely encrypted system is not debuggable
because by definition nothing is
"in the clear". Sure you can "read" it's RAM while
tweaking it's input ports
trying to discern what it's keys are based on
injecting known values but
asymmetrical is supposed to mean even with encryption
key, source plain data &
resulting encrypted data it's not going to reveal the
decryption key.
Look into the IronKey drive I was mentioning & you'll
understand it would be
damn hard to get at where the keys are "to connect
debuggers" & still be able to
retrieve keys nor a still working module. That module
as a SATA go-between would
mean your not getting into the drive without whatever
component unlocks the
encryption module.
Even with "flawed" TC on a Powered down system, no
trace keydata on the HDD, no
get in short of brute force (AES? TwoFish? much luck!)
FBI or not. Only option
would be "water boarding" and that's not going to
produce results if the keys
were on a component and destroyed vs. being a password
you can force out of a
subject.
Mesdaq, Ali wrote:
> Hardware is not really the solution. The problem is
layered but the main
> problem here is physical security. If you have a
system and all of its
> components to encrypt and decrypt are right there in
one piece and
> people can connect debuggers to it or analyze it
they could break
> anything you do. But if the system is not complete
without something
> else like a private key that needs to be retrieved
remotely then you
> have some extra security. Then you can control the
process by seeing if
> physical security is compromised you just don't send
that private key
> and the system is incomplete. For true secure
solutions you need to
> layer, then separate, then control access to each
layer and component.
> So in the case of hard drive encryption if an FBI
person gets your drive
> and you can bet they can find out everything on it
if they care enough.
>
> Security is really just a level of comfort you can
deal with. EVERYTHING
> can be compromised in some way.
>
____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs
