Re: cold boot attacks on disk encryption

[Perry E. Metzger]

"Ali, Saqib" <[EMAIL PROTECTED]> writes:
> i think in most cases tamper-resistant is sufficient - provided the
> device that can detect an attempt of tampering, and erase itself.

Clearly, if the anti-tamper mechanisms work, the device will not be
compromised. The problem is, such mechanisms don't always work. There
is lots of stuff in the literature about various kinds of attacks on
such devices.

Again, I will point out the following from my original comment:

>>  As always, the question is whether what you are protecting is
>>  worth more than the attackers would have to spend on the attack.

Perry

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: cold boot attacks on disk encryption

[Ali, Saqib]

i think in most cases tamper-resistant is sufficient - provided the
device that can detect an attempt of tampering, and erase itself. DRAM
chips referred to in this attack are not tamper-resistant.

http://www.linkedin.com/in/encryption


On Thu, Feb 21, 2008 at 2:59 PM, Perry E. Metzger <[EMAIL PROTECTED]> wrote:
>
>  "Ali, Saqib" <[EMAIL PROTECTED]> writes:
>
> > How about TPM? Would this type of attack work on a tamper-resistant ver1.2 
> > TPM?
>
>  The phrase is "tamper resistant", not "tamper proof". Depending on how
>  determined your attackers are, pretty much anything depending on
>  tamper resistant hardware will fall. As always, the question is
>  whether what you are protecting is worth more than the attackers would
>  have to spend on the attack.
>
>  --
>
>
> Perry E. Metzger[EMAIL PROTECTED]
>



-- 
Saqib Ali, CISSP, ISSAP
http://www.full-disk-encryption.net

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

wrt Cold Boot Attacks on Disk Encryption

[' =JeffH ']

From:David Farber <[EMAIL PROTECTED]>
Subject: [IP] Cold Boot Attacks on Disk Encryption -- report on 
To:  "ip" <[EMAIL PROTECTED]>
Date:Thu, 21 Feb 2008 16:25:43 -0500




Begin forwarded message:

From: Declan McCullagh <[EMAIL PROTECTED]>
Date: February 21, 2008 3:57:43 PM EST
To: [EMAIL PROTECTED]
Cc: Jacob Appelbaum <[EMAIL PROTECTED]>
Subject: Re: [IP] Cold Boot Attacks on Disk Encryption

Dave,

The paper published today makes some pretty strong claims about the  
vulnerabilities of Microsoft's BitLocker, Apple's FileVault,  
TrueCrypt, Linux's dm-crypt subsystem, and similar products.

So I put the folks behind it to a test. I gave them my MacBook laptop  
with FileVault turned on, powered up, encrypted swap enabled, and the  
screen saver locked.

They were in fact able to extract the 128-bit AES key; I've put screen  
snapshots of their FileVault bypass process here:
http://www.news.com/2300-1029_3-6230933-1.html

And my article with responses from Microsoft, Apple, and PGP is here:
http://www.news.com/8301-13578_3-9876060-38.html

Bottom line? This is a very nicely done attack. It's going to make us  
rethink how we handle laptops in sleep mode and servers that use  
encrypted filesystems (a mail server, for instance).

- -Declan

Jacob Appelbaum wrote:
> With all of the discussions that take place daily about laptop  
> seizures,
> data breech laws and how crypto can often come to the rescue, I  
> thought
> the readers of IP might be interested in a research project that was
> released today. We've been working on this for quite some time and are
> quite proud of the results.
> Ed Felten wrote about it on Freedom To Tinker this morning:
> http://www.freedom-to-tinker.com/?p=1257



- ---
Archives: http://www.listbox.com/member/archive/247/=now
RSS Feed: http://www.listbox.com/member/archive/rss/247/
Powered by Listbox: http://www.listbox.com

--

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: cold boot attacks on disk encryption

[Perry E. Metzger]

"Ali, Saqib" <[EMAIL PROTECTED]> writes:
> How about TPM? Would this type of attack work on a tamper-resistant ver1.2 
> TPM?

The phrase is "tamper resistant", not "tamper proof". Depending on how
determined your attackers are, pretty much anything depending on
tamper resistant hardware will fall. As always, the question is
whether what you are protecting is worth more than the attackers would
have to spend on the attack.

-- 
Perry E. Metzger[EMAIL PROTECTED]

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: cold boot attacks on disk encryption

[Jacob Appelbaum]

Ali, Saqib wrote:
> After thinking about this a bit, i have changed my views on this
> attack. i think it is quite easy to perform this attack. i myself have
> been in similar situations, where my personal computer could have been
> easily compromised by this attack

Usually when doing a demo of this attack, people change their minds
quickly. I'm pleased to hear that in actual use cases you acknowledge an
actual problem.

> 
> However, the hardware based encryption solutions like (Seagate FDE)
> would easily deter this type of attacks, because in a Seagate FDE
> drive the decryption key never gets to the DRAM. The keys always
> remain in the Trusted ASIC on the drive.
> 

While riding the BART this morning, I ran into Nate Lawson (from
Cryptography Research). He mentioned that he felt people would reply
with such endorsements. I'd like to take the time to disagree with
endorsing hardware products as a solution. Hardware solutions are going
to be hard to attack in some circumstances. But they may in fact be
worse without fully viewable (or Free) source software (for the
firmware, the FPGA or the layout of the ASIC, etc.

A great example of some so called "unbreakable" hardware disk crypto is
this snakeoil:
http://it.slashdot.org/article.pl?sid=08/02/19/0213237
http://www.heise-online.co.uk/security/Enclosed-but-not-encrypted--/features/110136

"A new generation of inexpensive disk drive enclosures using hardware
encryption and RFID keys do not fulfil the promises of their publicity.
The adverts claim 128-bit AES hardware encryption, but they don't tell
us how it is used."

Without transparency, I'd rather stick with software. It has issues, we
now know about another one.

Regards,
Jacob Appelbaum

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: cold boot attacks on disk encryption

[Sherri Davidoff]

As soon as I heard about this research I had to try it out. My laptop 
(Thinkpad) has an encrypted Truecrypt partition.  I quickly made a 
modified bootable DSL usb memory dumper, powered the machine down, 
waited a minute, dumped memory, and found that I could recover passwords 
from multiple prior reboots. I was able to recover my Truecrypt password 
even if the volume was not mapped at the time of reboot, as well as GPG 
passwords, SSH passwords, etc etc. It was really easy.


During physical pentests, when I grab an encrypted laptop from an 
office, my clients usually respond that the laptop was "encrypted" and 
the data was therefore safe. That's not necessarily true, of course, but 
we don't have the time during these engagements to test out the security 
of the encryption products/implementation, and neither do most attackers.


Now attackers (or customs) just have to grab a live laptop, plug in a 
USB memory dumper and power cycle the system in order to obtain a 
dictionary of likely passwords and potentially recover encryption keys. 
Presumably tools to to accomplish this will soon be found in the wild 
and will become accessible to attackers with even low levels of 
technical skill.


I imagine this will eventually have a big impact on the way 
organizations respond to stolen mobile device incidents. With the 
current technology, if a laptop or mobile device is on when it's stolen, 
companies will need to assume that the data is gone, regardless of 
whether or not encryption products have been deployed.


Anyone familar with the laws in the arena? Are there regulations which 
require reporting only if data on a stolen device is not encrypted?


Sherri



Ali, Saqib wrote:

interesting paper. but i fail to see how this could be "deadly" (as
the author puts it) to the disk encryption products.

This methods requires the computer to be "recently" turned-on and unlocked.

So the only way it would work is that the victim unlocks the disks
i.e. enter their preboot password and turn off the computer and
"immediately" handover (conveniently) the computer to the attacker so
that the attacker remove the DRAM chip and store in nitrogen. And the
attacker has to do all this in less then 2 seconds :) If the
attacker is standing right next to the victim, why even let the victim
turn-off the unlocked computer

Or am I missing something?



-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: cold boot attacks on disk encryption

[Ali, Saqib]

>  Umm, pardon my bluntness, but what do you think the FDE stores the key
>  in, if not DRAM? The encrypting device controller is a computer system
>  with a CPU and memory. I can easily imagine what you'd need to build
>  to do this to a disk drive. This attack works on anything that has RAM.

How about TPM? Would this type of attack work on a tamper-resistant ver1.2 TPM?

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: cold boot attacks on disk encryption

[Jon Callas]

On Feb 21, 2008, at 12:14 PM, Ali, Saqib wrote:


However, the hardware based encryption solutions like (Seagate FDE)
would easily deter this type of attacks, because in a Seagate FDE
drive the decryption key never gets to the DRAM. The keys always
remain in the Trusted ASIC on the drive.


Umm, pardon my bluntness, but what do you think the FDE stores the key  
in, if not DRAM? The encrypting device controller is a computer system  
with a CPU and memory. I can easily imagine what you'd need to build  
to do this to a disk drive. This attack works on anything that has RAM.


Jon

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: cold boot attacks on disk encryption

[Bill Frantz]

[EMAIL PROTECTED] (Perry E. Metzger) on Thursday, February 21, 2008 wrote:

>
>Ed Felten blogs on his latest research:
>
>http://www.freedom-to-tinker.com/?p=1257
>
>Excerpt:
>
>Today eight colleagues and I are releasing a significant new
>research result. We show that disk encryption, the standard
>approach to protecting sensitive data on laptops, can be defeated
>by relatively simple methods. We demonstrate our methods by using
>them to defeat three popular disk encryption products: BitLocker,
>which comes with Windows Vista; FileVault, which comes with MacOS
>X; and dm-crypt, which is used with Linux.
>
>More info: http://citp.princeton.edu/memory
>
>Paper: http://citp.princeton.edu.nyud.net/pub/coldboot.pdf

Their key recovery technique gets a lot of mileage from using the
computed key schedule for each round of AES or DES to provide
redundant copies of the bits of the key.  If the computer cleared
the key schedule storage, while keeping the key itself when the
system is in sleep mode, or when the screen-saver password mode
kicks in, this attack would be less possible.

If, in addition, the key was kept XORed with the secure hash of a
large block of random memory, as suggested in their countermeasures
section, their attacks would be considerably more difficult.

These seem to be simple, low overhead countermeasures that provide
value for machines like laptops in transit.

Cheers - Bill

-
Bill Frantz| The first thing you need when  | Periwinkle
(408)356-8506  | using a perimeter defense is a | 16345 Englewood Ave
www.pwpconsult.com | perimeter. | Los Gatos, CA 95032

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: cold boot attacks on disk encryption

[Jacob Appelbaum]

Hi,

I'm one of the coauthors of the paper and I'd love to chime in.

Perry E. Metzger wrote:
> "Ali, Saqib" <[EMAIL PROTECTED]> writes:
>> This methods requires the computer to be "recently" turned-on and unlocked.
> 
> No, it just requires that the computer was recently turned on. It need
> not have been "unlocked" -- it jut needed to have keying material in RAM.
> 

This is correct.

>> So the only way it would work is that the victim unlocks the disks
>> i.e. enter their preboot password and turn off the computer and
>> "immediately" handover (conveniently) the computer to the attacker so
>> that the attacker remove the DRAM chip and store in nitrogen.
> 
> LN2 is pretty trivial to get your hands on, and will remain happy and
> liquid in an ordinary thermos for quite some hours or longer. However,
> the authors point out that canned air works fine, too.
> 

Yes, this is also correct. Canned air is often found in server rooms. An
attacker might not even need to bring anything with them to leverage
this attack.

>> And the attacker has to do all this in less then 2 seconds :)
> 
> No, they may even have minutes depending on the RAM you have.
> 

This is an important point. Without cooling, it's not merely a matter of
a second or less. This is a common misconception that even in light of
new evidence is difficult to believe. I think reading our paper and
understanding our graphs should help with this.

>> Or am I missing something?
> 
> People readily assume that rebooting or turning off a computer wipes
> RAM. It doesn't. This is just more evidence that it is bad
> to assume that the contents of RAM are gone even if you turn off the
> machine.

Yes. General purpose memory isn't a safe place to store keying material
and software countermeasures are a step behind. Even with obfuscated key
schedules or strange byte ordering, the physical properties of the
memory chips are going to be difficult to overcome.

As our paper states: "There is no easy solution to this problem."

I'm happy to field questions if this is the proper forum.

Best,
Jacob Appelbaum

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: cold boot attacks on disk encryption

[Perry E. Metzger]

"Ali, Saqib" <[EMAIL PROTECTED]> writes:
> However, the hardware based encryption solutions like (Seagate FDE)
> would easily deter this type of attacks, because in a Seagate FDE
> drive the decryption key never gets to the DRAM. The keys always
> remain in the Trusted ASIC on the drive.

I'm sure that the same sort of attacks used to get keying material out
of other ASICs and out of smart cards could be applied to the ASICs on
the drive controller board. No one has tried yet, of course, but I see
no reason they wouldn't succeed.

Perry

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: cold boot attacks on disk encryption

[Len Sassaman]

On Thu, 21 Feb 2008, Perry E. Metzger wrote:

>
> "Ali, Saqib" <[EMAIL PROTECTED]> writes:
> > This methods requires the computer to be "recently" turned-on and unlocked.
>
> No, it just requires that the computer was recently turned on. It need
> not have been "unlocked" -- it jut needed to have keying material in RAM.

Indeed. Given the recent discussions of border searches of laptops, I
wouldn't be surprised to see this technique used against locked laptops in
suspended mode.

The idea that data in RAM doesn't automatically disappear the instant the
computer is powered off isn't the really interesting thing in this paper,
though, at least for me. I'm more intrigued by the error-correction
techniques they use to apparently recover AES keys that have degraded by
up to 10% of their bits.

It would be nice if the authors released their tools so that other
researchers can build on this.


--Len.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: cold boot attacks on disk encryption

[Ali, Saqib]

After thinking about this a bit, i have changed my views on this
attack. i think it is quite easy to perform this attack. i myself have
been in similar situations, where my personal computer could have been
easily compromised by this attack

However, the hardware based encryption solutions like (Seagate FDE)
would easily deter this type of attacks, because in a Seagate FDE
drive the decryption key never gets to the DRAM. The keys always
remain in the Trusted ASIC on the drive.


On Thu, Feb 21, 2008 at 11:51 AM, Perry E. Metzger <[EMAIL PROTECTED]> wrote:
>
>  "Ali, Saqib" <[EMAIL PROTECTED]> writes:
>  > This methods requires the computer to be "recently" turned-on and unlocked.
>
>  No, it just requires that the computer was recently turned on. It need
>  not have been "unlocked" -- it jut needed to have keying material in RAM.
>
>
>  > So the only way it would work is that the victim unlocks the disks
>  > i.e. enter their preboot password and turn off the computer and
>  > "immediately" handover (conveniently) the computer to the attacker so
>  > that the attacker remove the DRAM chip and store in nitrogen.
>
>  LN2 is pretty trivial to get your hands on, and will remain happy and
>  liquid in an ordinary thermos for quite some hours or longer. However,
>  the authors point out that canned air works fine, too.
>
>
>  > And the attacker has to do all this in less then 2 seconds :)
>
>  No, they may even have minutes depending on the RAM you have.
>
>
>  > Or am I missing something?
>
>  People readily assume that rebooting or turning off a computer wipes
>  RAM. It doesn't. This is just more evidence that it is bad
>  to assume that the contents of RAM are gone even if you turn off the
>  machine.
>
>  Perry
>



-- 
Saqib Ali, CISSP, ISSAP
http://www.full-disk-encryption.net

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: cold boot attacks on disk encryption

[Jack Lloyd]

On Thu, Feb 21, 2008 at 12:10:33PM -0500, Perry E. Metzger wrote:
> 
> Ed Felten blogs on his latest research:
> 
> http://www.freedom-to-tinker.com/?p=1257
> 
> Excerpt:
> 
> Today eight colleagues and I are releasing a significant new
> research result. We show that disk encryption, the standard
> approach to protecting sensitive data on laptops, can be defeated
> by relatively simple methods. We demonstrate our methods by using
> them to defeat three popular disk encryption products: BitLocker,
> which comes with Windows Vista; FileVault, which comes with MacOS
> X; and dm-crypt, which is used with Linux.

While they did have some success with recovering an entire AES key
schedule uncorrupted, it seems important to note that the simplistic
nature of the AES and DES key schedules allowed them to recover the
entire original key even after the state had been somewhat degraded
with only moderate amounts of work. A cipher with a better key
schedule (Blowfish or Serpent, for instance) would seem to offer some
defense here.

Jack

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: cold boot attacks on disk encryption

[Perry E. Metzger]

"Ali, Saqib" <[EMAIL PROTECTED]> writes:
> This methods requires the computer to be "recently" turned-on and unlocked.

No, it just requires that the computer was recently turned on. It need
not have been "unlocked" -- it jut needed to have keying material in RAM.

> So the only way it would work is that the victim unlocks the disks
> i.e. enter their preboot password and turn off the computer and
> "immediately" handover (conveniently) the computer to the attacker so
> that the attacker remove the DRAM chip and store in nitrogen.

LN2 is pretty trivial to get your hands on, and will remain happy and
liquid in an ordinary thermos for quite some hours or longer. However,
the authors point out that canned air works fine, too.

> And the attacker has to do all this in less then 2 seconds :)

No, they may even have minutes depending on the RAM you have.

> Or am I missing something?

People readily assume that rebooting or turning off a computer wipes
RAM. It doesn't. This is just more evidence that it is bad
to assume that the contents of RAM are gone even if you turn off the
machine.

Perry

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: cold boot attacks on disk encryption

[Ali, Saqib]

interesting paper. but i fail to see how this could be "deadly" (as
the author puts it) to the disk encryption products.

This methods requires the computer to be "recently" turned-on and unlocked.

So the only way it would work is that the victim unlocks the disks
i.e. enter their preboot password and turn off the computer and
"immediately" handover (conveniently) the computer to the attacker so
that the attacker remove the DRAM chip and store in nitrogen. And the
attacker has to do all this in less then 2 seconds :) If the
attacker is standing right next to the victim, why even let the victim
turn-off the unlocked computer

Or am I missing something?

-- 
Saqib Ali,
http://www.full-disk-encryption.net


On 2/21/08, Perry E. Metzger <[EMAIL PROTECTED]> wrote:
>
>  Ed Felten blogs on his latest research:
>
>  http://www.freedom-to-tinker.com/?p=1257
>
>  Excerpt:
>
> Today eight colleagues and I are releasing a significant new
> research result. We show that disk encryption, the standard
> approach to protecting sensitive data on laptops, can be defeated
> by relatively simple methods. We demonstrate our methods by using
> them to defeat three popular disk encryption products: BitLocker,
> which comes with Windows Vista; FileVault, which comes with MacOS
> X; and dm-crypt, which is used with Linux.
>
>  More info: http://citp.princeton.edu/memory
>
>  Paper: http://citp.princeton.edu.nyud.net/pub/coldboot.pdf
>
>
>
>  --
>  Perry E. Metzger[EMAIL PROTECTED]
>
>  -
>  The Cryptography Mailing List
>  Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
>

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

cold boot attacks on disk encryption

[Perry E. Metzger]

Ed Felten blogs on his latest research:

http://www.freedom-to-tinker.com/?p=1257

Excerpt:

Today eight colleagues and I are releasing a significant new
research result. We show that disk encryption, the standard
approach to protecting sensitive data on laptops, can be defeated
by relatively simple methods. We demonstrate our methods by using
them to defeat three popular disk encryption products: BitLocker,
which comes with Windows Vista; FileVault, which comes with MacOS
X; and dm-crypt, which is used with Linux.

More info: http://citp.princeton.edu/memory

Paper: http://citp.princeton.edu.nyud.net/pub/coldboot.pdf


-- 
Perry E. Metzger[EMAIL PROTECTED]

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Interesting New Developments in SocGen

[Jon Callas]

Excerpt:

   An internal investigation into billions of euros of losses at
   Societe Generale has found that controls at the French bank
   "lacked depth".

   The results of the investigation also show that rogue trades
   were first made back in 2005.



Excerpt:

   Societe Generale made a profit in 2007 despite a trading scandal  
that

   cost the bank 4.9bn euros ($7bn; £3.7bn).

   The French bank said it made a net profit of 947m euros for the  
year,

   although this was down 82% from 2006.

I think these two things are very interesting from a viewpoint of  
security and economics. This fellow had been making unauthorized  
trades for two to three years, and when it all came tumbling down, it  
knocked off at most 82% of one year's profits. (I say at most because  
it's reasonable to think that in a year of subprime issues, they'd  
have been down 30-50%.)


Compare and contrast with Nick Leeson's sinking of Baring's, which was  
a mere $1.4bn. We can even double-ish that to say $3bn to account for  
the intervening time.


Both cases were unauthorized trades spinning out of control in  
attempts to cover small losses, but Baring's was sunk for the  
(adjusted) $3bn and SocGen merely loses 80% of one year's profits at  
$5bn.


Does this suggest that what is really needed is a way to detect losses  
that could spin out of control before they do, as opposed to direct  
security mechanisms?


Jon

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Irish blood donor records

[David Malone]

It seems that disk containing records of the Irish Blood Transfusion
service seems to have been stolen in New York:

http://www.rte.ie/news/2008/0219/blood.html

Thankfully, the data was encrypted. The head of the IBTS said on
the news that there was a remote possibility of access, roughly
equivelent to winning the Euromillions Lottery 10 times in a row.
Based on the jackpot odds from:

http://en.wikipedia.org/wiki/EuroMillions

they are probably thinking around lg(76275360)*10 = 261.84, or 256
bits of key.

David.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

USB drive manufacturer encrypts data with XOR

[Rui Paulo]

From 
http://www.heise-online.co.uk/security/Enclosed-but-not-encrypted--/features/110136

"The specifications of the 2.5in. Easy Nova Data Box PRO-25UE RFID  
hard drive case by German vendor Drecom sound promising: hardware data  
encryption with 128-bit AES, access control via an RFID chip compact  
enough to carry around on your key ring and optional 160GB or 250GB  
hard disk capacity. Swiping the RFID chip along the case causes the  
integrated Innmax IM7206 crypto controller to reveal the drive as a  
USB 2.0 mass storage compatible device to the attached computer. This  
works under Linux and Mac OS X as well as Windows.

[...]
These regular repetitions continued, and the almost identical columns  
of numbers suggest that the 512-byte sectors of your drive are not in  
fact encrypted with AES, but merely with a constant 512-byte cipher  
block applied as an XOR (exclusive OR)."


--
Rui Paulo

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: Fixing SSL (was Re: Dutch Transport Card Broken)

[Thierry Moreau]

Leichter, Jerry wrote:


While trying to find something else, I came across the following
reference:

Title:   Sender driven certification enrollment system
Document Type and Number:  United States Patent 6651166
Link to this page:  http://www.freepatentsonline.com/6651166.html
Abstract:
A sender driven certificate enrollment system and methods of its
use are provided, in which a sender controls the generation of a
digital certificate that is used to encrypt and send a document
to a recipient in a secure manner. The sender compares
previously stored recipient information to gathered information
from the recipient. If the information matches, the sender
transfers key generation software to the recipient, which
produces the digital certificate, comprising a public and
private key pair. The sender can then use the public key to
encrypt and send the document to the recipient, wherein the
recipient can use the matching private key to decrypt the
document.



Some feedback on the above security certificate issuance process.

At first, it seems neat. But then, looking at how it works in practice:

the client receives an e-mail notification soliciting him to click on a
HTML link and then enroll for a security certificate,

the client is solicited exactly like a phishing criminal would do, and

a java software utility downloaded from the web should not be allowed to
modify security-critical parameters on the local machine.


According to my records, this issuance process is nonetheless
representative of research directions for user enrollment, i.e. there
aren't too many other documented processes in this area.

Regards,


--

- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada   H2M 2A1

Tel.: (514)385-5691
Fax:  (514)385-5900

web site: http://www.connotech.com
e-mail: [EMAIL PROTECTED]



-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: Toshiba shows 2Mbps hardware RNG

[Simon Josefsson]

David Wagner <[EMAIL PROTECTED]> writes:

> Crawford Nathan-HMGT87 writes:
>>One of the problems with the Linux random number generator
>>is that it happens to be quite slow, especially if you need a lot of
>>data.
>
> /dev/urandom is blindingly fast.  For most applications, that's
> all you need.

Alas, reading from /dev/urandom depletes the entropy pool much like
reading from /dev/random does.  So if you read a lot of data from
/dev/urandom, you make /dev/random unusable in practice.  This problem
has hit libgcrypt/gnutls via the MTA Exim on a lot of Debian systems.  I
would argue that the linux kernel /dev/*random system is sub-optimally
designed, reading a lot of data from /dev/urandom should not cause the
system's /dev/random to be unusable.

(Admittedly, there were other design flaws in how exim used gnutls, such
as re-generating the DH parameters every X hour, and doing that
synchronously in the SMTP process, causing them all to stall waiting for
entropy, but that has been fixed.)

/Simon

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Problems with the SRP Protocol paper?

[Jonathan Herzog]

Greetings--

A new list-member here, so please forgive me if this is off-topic or  
has been discussed before. However, I've recently discovered a  
problem with the proof of security for the Secure Remote Password  
(SRP) Protocol, and Ivan Krstic recommended that I ask about it here.


In particular: The SRP protocol is a password-based authenticated key- 
exchange protocol that has been recently added to the TLS standard  
[RFC 5054] and the IEEE standard P1363.2. It is based on Diffie- 
Hellman, and claims to have all sorts of security properties.  
However, the original paper on the protocol [Wu, 1997] is somewhat  
unsatisfying from a mathematical viewpoint. First, it fails to  
rigorously define the properties the protocol is to meet, and gives  
only English-language intuitions. Secondly, it sometimes fails to  
argue that the protocol meets even those intuitions. Lastly, some of  
the crucial arguments of security are flawed in deep, deep ways.


The first two types of problems above are perhaps forgivable: the  
paper was published back in 1997 and cryptographers are still arguing  
today about how exactly to formally define security for these kinds  
of protocols. The last problem, however, is more worrisome. In  
particular, the 'proof' of security for SRP shows (correctly) that in  
certain cases, the problem of breaking SRP is exactly the same as  
breaking Diffie-Hellman. That is, Diffie-Hellman is a *special case*  
of SRP. Therefore, if one can break *all* instances of SRP, then one  
can break Diffie-Hellman and thus SRP is as secure as Diffie-Hellman.


However, this last step is wrong, at least in the area of  
cryptography. If we were talking about NP-completeness, then yes,  
this argument would work. But in crypto, we can't necessarily judge a  
crypto primitive by its hardest case.  We need to talk about the  
ability of the adversary to break a non-negligible *fraction* of  
cases. After all, the above 'proof' of security leaves open the  
possibility that it is easy to break those instances of SRP (the vast  
majority, actually) which *don't* directly encode a Diffie-Hellman  
problem.


Of course, this flaw in the proof can be fixed. It is straightforward  
to do the proof right, and to show that a random instance of a Diffie- 
Hellman problem can be transformed into a random instance of the SRP  
protocol. But the flaw in the paper is worrisome. Is this a known  
problem that has been addressed by later literature? Does anyone know  
of an analysis of SRP that measures the protocol against any of the  
recently-formulated definitions of security [Bellare & Rogaway 1994;  
Bellare, Pointcheval & Rogaway 2000, Canetti et al 2005]? In other  
words, do we know more about the security of SRP than is contained in  
the original 1997 paper?


Thanks.

--
Jonathan Herzog
Cryptographic consulting
[EMAIL PROTECTED]
www.jonathanherzog.com

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

RE: Toshiba shows 2Mbps hardware RNG

[Alexander Klimov]

On Wed, 13 Feb 2008, Dave Korn wrote:
> On 11 February 2008 17:37, Crawford Nathan-HMGT87 wrote:
> > I'm wondering if they've considered the possibility of EMI skewing
> > the operation of the device, or other means of causing the device
> > to genearate "less than completely random" numbers.
>
>   Not necessarily a problem, although it does depend on their
> design.  Even if by saturating the chip in an intense EM field you
> can skew the result almost all the way to 1 or 0, won't the standard
> debiassing trick of examining successive pairs of bits handle that?

It depends on the attack: Consider John von Neumann's algorithm
that, say, outputs the first bit in each pair if bits are
different. If you apply EM attack and get 0s almost everywhere

 00 00 00 01 00 00 00 10 00 00 10 00 00

but cannot control where 1s are exactly, then JvN corrector helps, but
if your EM attack is such that it makes long runs of 0s and 1s

 00 00 00 11 11 11 10 00 00 00 01 11 11

and you can detect when the bits are produced then you know exactly
what bits are produced (if a bit produced on transition from 0s to 1s
then it is 0).


Considering speed of nondeterministic RNG, it seems pointless at least
for those who go thru FIPS certification. FIPS 140-2 says

  Commercially available nondeterministic RNGs may be used for
  the purpose of generating seeds for Approved deterministic
  RNGs. [...] An Approved RNG shall be used for the generation
  of cryptographic keys used by an Approved security function.
  The output from a non-Approved RNG may be used 1) as input
  (e.g., seed, and seed key) to an Approved deterministic RNG or
  2) to generate initialization vectors (IVs) for Approved
  security function(s).

and currently there is no Approved nondeterministic RNG, so the
only option is to use nondeterministic RNG to generate seeds
for the deterministic one and one does not need MBps speed to
generate a seed.

But again, comparing a useful feature and a check mark on
marketing slides, the latter is doomed to be implemented.

-- 
Regards,
ASK

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: kit to prevent computers from losing power during seizure.

[Peter Gutmann]

"Perry E. Metzger" <[EMAIL PROTECTED]> writes:

>It appears that disk encryption techniques are spawning technical responses.
>This gadget lets law enforcement take a computer without ever turning off the
>power.

For those who don't want to plough through the docs, it looks like a static
transfer switch that requires you to take a tap from a mains line and feed it
to a UPS.  The "tap" relies on either having the PC on a power strip or
stripping the mains flex and attaching jumpers.  So the setup before is:

  Mains ---+-- PC
   |
  UPS   --- STS ---+

When you unplug the resulting setup from the wall, the HotPlug device detects
the voltage loss (in other words it contains a portion of a UPS switchover
circuit, the static transfer switch, which is just some SCRs operating as a
zero-crossing switch and a controller IC) and switches over to the UPS:

   +-- PC
   |
  UPS   --- STS ---+

and you can remove the PC.

I was going to suggest that given the usual LE-targeted device pricing (five
figures and up) it'd probably be cheaper to buy a commercial STS, but at only
$500 it's quite reasonably priced.

>Countermeasures are, of course, quite possible.

And successively more Rube-Goldberg :-).

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: Toshiba shows 2Mbps hardware RNG

[Peter Gutmann]

"Steven M. Bellovin" <[EMAIL PROTECTED]> writes:

>Remember the Clipper chip?

Clipper (or more specifically Capstone, via the Fortezza card) is a great
example of the NSA's sound engineering approach to generating random data [0].
They used a physical randomness source of an unpublished type, presumably a
standard noise-based source.  And a Skipjack-based ANSI X9.17 PRNG with a pre-
set random seed.  *And* a 48-bit counter.  All were mixed up with SHA-1.  The
design was such that there was no single point of failure in the sources
themselves, so that as long as SHA-1 was at least vaguely useful as a mixing
function the sources themselves didn't have to be totally failure-proof.  For
example if some environmental condition reduced the utility of the noise-based
source, the PRNG would still provide strong input.  If the PRNG locked up for
some reason, the secret seed for that combined with the counter would still
provide varying input to the SHA-1 step.  I assume they also sampled the
output as per FIPS 140 to detect a lockup of the SHA-1 step.  The result was a
failure-tolerant design that didn't rely on the totally failure-proof
operation of a single component in order to function.

Peter.

[0] I'm calling it a "sound engineering approach" because I did the same thing
in my PRNG design (independent of Fortezza).  Others may wish to call it
"excessively paranoid" and other things :-).

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

announcing allmydata.org "Tahoe" v0.8

[zooko]

ANNOUNCING: Allmydata.org "Tahoe" version 0.8

We are pleased to announce the release of version 0.8 of allmydata.org
"Tahoe".

Allmydata.org "Tahoe" is a secure, decentralized, fault-tolerant
filesystem.  All of the source code is available under a Free
Software, Open Source licence (or two).

This filesystem is encrypted and distributed over multiple peers in
such a way that it continues to work correctlly even when some of the
peers are unavailable, malfunctioning, or malicious.

This is the successor to Allmydata-Tahoe v0.7, which was released
January 8, 2008 [1].

This release improves performance, diagnostics, and packaging.  This
release of allmydata.org "Tahoe" will form the basis of the next
consumer backup product from Allmydata, Inc. -- http://allmydata.com .


Since v0.7 we've made the following changes:

 * Add a preliminary Microsoft Windows package (ticket #195).

 * Add a preliminary Macintosh package (ticket #182).

 * Display information about peers (ticket #32).

 * Display information about uploads and downloads (ticket #39).

 * Add unit tests and docs for contrib/fuse (ticket #255).

 * Add a preliminary FUSE interface for Macintosh.

 * Update docs, starting with docs/about.html --
   http://allmydata.org/source/tahoe/trunk/docs/about.html .

 * Improve logging, diagnostic tools, statistics, timing measurements
   during upload, etc..

 * Add more measurements of performance:
   http://allmydata.org/trac/tahoe/wiki/Performance .

 * Add an upload helper, with resumption of incomplete uploads and
   short-circuiting of uploads if the file is already present (tickets
   #116, #258, #218).

 * Make upload continue even if some servers disappear during the
   upload process.

 * Add mtime and ctime timestamps to files (ticket #183).

 * Make introduction more efficient by allowing nodes to act as
   clients-only and not publish themselves as servers (ticket #271).

 * Extend the web API to allow programmatic control of mutable files.

 * Fix potential problem that could cause corruption of downloaded
   mutable files if a long series of unlikely coincidences and hacked
   clients occurred (ticket #312).

 * Make file and directory names use unicode.

 * Use SHA-256d instead of SHA-256 for secure hashes.


WHAT IS IT GOOD FOR?

With Tahoe, you can distribute your filesystem across a set of
computers, such that if some of the computers fail or turn out to be
malicious, the filesystem continues to work from the remaining
computers.  You can also share your files with other users, using a
strongly encrypted, capability-based access control scheme.

This release is targeted at hackers and smart users who are willing to
use a web user interface, a command-line user interface, or a FUSE
interface.  (Or a RESTful API.  Just telnet to localhost and type HTTP
requests to get started.)

Because this software is new, it is not yet recommended for storage of
highly confidential data nor for valuable data which is not otherwise
backed up. However, it works well in practice, it comes with extensive
unit tests [2], and there are no known security flaws which would
compromise confidentiality or data integrity.  (For a current
description of all known security issues and an overview of Tahoe's
security properties, please see the Security web page: [3].)

This release of Tahoe is suitable for the "friendnet" use case [4] --
it is easy to create a filesystem spread over the computers of you and
your friends so that you can share files and disk space with one
another.


LICENCE

You may use this package under the GNU General Public License, version
2 or, at your option, any later version.  See the file "COPYING.GPL"
for the terms of the GNU General Public License, version 2.

You may use this package under the Transitive Grace Period Public
Licence, version 1.0.  The Transitive Grace Period Public Licence says
that you may distribute proprietary derived works of Tahoe without
releasing the source code of that derived work for up to twelve
months, after which time you are obligated to release the source code
of the derived work under the Transitive Grace Period Public Licence.
See the file "COPYING.TGPPL.html" for the terms of the Transitive
Grace Period Public Licence, version 1.0.

(You may choose to use this package under the terms of either licence,
at your option.)


INSTALLATION

Tahoe works on Linux, Mac OS X, Windows, Cygwin, and Solaris.  For
installation instructions please see "doc/install.html" [5].


HACKING AND COMMUNITY

Please join us on the mailing list [6] to discuss uses of Tahoe.
Patches that extend and improve Tahoe are gratefully accepted -- the
RoadMap page [7] shows the next improvements that we plan to make and
CREDITS [8] lists the names of people who've contributed to the
project.  The wiki Dev page [9] contains resources for hackers.


SPONSORSHIP

Tahoe is sponsored by Allmydata, Inc. [10], a provider of consumer
backup services.  Allmydata, Inc. contributes hardware, software,
i

Re: House o' Shame: Amtrak

[John Levine]

>  http://amtrak.bfi0.com/.

>Lesson for phishers: If you want your phish to seem more legit, outsource it
>to Bigfoot Interactive, which seems to lead back to Epsilon Agency Services,
>who specialise in... well, phishing, but for the good guys.  I bet the Russian
>Business Network could do it for less though :-).

Having dealt at length with people from BFI/Epsilon, I can confirm that
many of them are not the sharpest needles in the etui.

This problem is well known in the ESP (bulk mail for hire) industry,
and the better ones know how to deal with it.  If you are on Orbitz'
mailing list, for example, the mail comes from [EMAIL PROTECTED],
and the links in the mail all go to http://my.orbitz.com/whatever.  Do
a few DNS lookups and you'll find NS records from Orbitz that delegate
my.orbitz.com to Responsys, their ESP.  This is a straightforward and
effective way to manage the namespace for outsourced mail, and my
biggest question is why so many ESPs don't do it yet.

R's,
John

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: kit to prevent computers from losing power during seizure.

[Dirk-Willem van Gulik]

On Fri, 15 Feb 2008, Perry E. Metzger wrote:
>
> It appears that disk encryption techniques are spawning technical
> responses. This gadget lets law enforcement take a computer without
> ever turning off the power.
>
> http://www.wiebetech.com/products/HotPlug.php
>
> Countermeasures are, of course, quite possible.

There is another interesting one there - which is just as crucial, or
perhaps even more so, and effective --
http://www.wiebetech.com/products/MouseJiggler.php

Interestingly enough - there is already enough counter measure/detection
going on that there are variants - which move the mouse slower and
identify diferently (e.g. as a graphpad) as to voil simple 'count the # of
mouse counts'

Dw

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]