[mdlug] Dick encryption

[David Lane]

It is good programming practice to zero memory resources before you release them.

David 

----- Original Message ----
From: Raymond McLaughlin <driveray at ameritech.net>
To: MDLUG's Main discussion list <mdlug at mdlug.org>
Sent: Friday, February 22, 2008 1:49:28 PM
Subject: Re: [mdlug] Dick encryption


Jeff 
Hanson 
wrote:
> 
On 
Fri, 
Feb 
22, 
2008 
at 
10:53 
AM, 
Garry 
Stahl 
<tesral at comcast.net> 
wrote:
>> 
http://www.networkworld.com/news/2008/022108-disk-encryption-cracked.html?page=1
>>
>>  
Network 
World 
article 
pointing 
out 
that 
who 
controls 
the 
physical
>>  
computer, 
controls 
the 
data 
in 
it.  
There 
is 
a 
method 
to 
crack 
disk
>>  
encryption.  
It 
ain't 
easy, 
and 
you 
would 
have 
to 
have 
it 
ready, 
but 
it
>>  
is 
possible.
> 
> 
The 
security 
implications 
of 
loading 
the 
decryption 
keys 
into 
DRAM 
is
> 
something 
I 
though 
of 
myself 
a 
while 
ago.  
I 
hadn't 
realized 
that 
the
> 
data 
retention 
was 
that 
long 
without 
power 
or 
that 
cooling 
them 
could
> 
increase 
the 
data 
lifetime.

I 
was 
likewise 
surprised 
by 
this. 
It 
seems 
like 
motherboard
manufacturers 
adding 
a 
"zero 
all 
memory" 
routine 
to 
power 
up, 
reset,
and 
power 
down 
routines 
could 
go 
quite 
a 
ways 
toward 
mitigating 
this
concern.

For 
that 
matter, 
couldn't 
a 
"key 
flush" 
routine 
be 
added 
to 
umount
routines 
to 
zero 
the 
memory 
location 
that 
held 
the 
key. 
DRAM 
is 
not
magnetic 
media 
that 
retains 
"shadows" 
of 
its 
previous 
states.

> 
My 
theory 
was 
that 
it 
would 
be 
possible
> 
to 
read 
the 
memory 
bus 
while 
the 
system 
was 
active 
and 
pick 
up 
the
> 
keys 
that 
way. 

But 
that 
would 
require 
physical 
access 
to 
the 
memory 
bus, 
in 
which 
case
you 
are 
"owned" 
from 
the 
get 
go.

<SNIP>

> 
The 
only
> 
advantage 
they 
offer 
is 
a 
more 
complicated 
architecture 
that 
would
> 
have 
to 
be 
reverse 
engineered 
first 
so 
that 
an 
attacker 
would 
know
> 
where 
to 
look 
before 
attempting 
to 
find 
the 
key 
(obfuscation).  
I 
was
> 
thinking 
that 
storing 
the 
key 
in 
a 
CPU 
register 
would 
be 
better 
as 
the
> 
complexity 
and 
small 
feature 
size 
would 
make 
it 
a 
lot 
harder 
to
> 
extract.  
OpenBSD, 
IIRC, 
randomizes 
memory 
locations 
so 
theoretically
> 
it 
would 
be 
more 
difficult 
to 
find 
a 
key 
(again 
obfuscation).

Obfuscation 
wouldn't 
provide 
much 
protection. 
I've 
seen 
other 
article
mentioning 
researcher 
who's 
developed 
algorithms 
for 
finding 
crypto 
keys
in 
memory 
dumps, 
including 
"error 
correction" 
schemes 
to 
compensate 
for
bit 
rot.

> 
I 
think
> 
the 
Linux 
solution 
is 
to 
have 
the 
kernel 
wipe 
entire 
memory 
space
> 
before 
halting 
or 
suspending.

Ah, 
yes 
that's 
my 
suggestion, 
you 
did 
beat 
me 
to 
it.

I 
think 
an 
understated 
aspect 
of 
this 
situation 
is 
that 
it 
pertains 
to
encrypted 
filesystems 
which 
were 
"very 
recently" 
mounted. 
I 
think
something 
to 
be 
taken 
away 
from 
this 
is 
that 
an 
encrypted 
file 
system
that's 
"always 
mounted" 
isn't 
really 
very 
protected.

 
This 
also 
speaks 
well 
of 
powering 
notebook 
computers 
all 
the 
way 
down,
rather 
than 
suspending, 
before 
transport, 
if 
the 
security 
of 
encrypted
information 
is 
important.

Raymond 
McLaughlin

_______________________________________________
mdlug 
mailing 
list
mdlug at mdlug.org
http://mdlug.org/mailman/listinfo/mdlug






      ____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs