Re: handling weak keys using random selection and CSPRNGs

2006-10-12 Thread Steven M. Bellovin
Given how rare weak keys are in modern ciphers, I assert that code to cope
with them occurring by chance will never be adequately tested, and will be
more likely to have security bugs.  In short, why bother?

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


Re: TPM disk crypto

2006-10-12 Thread Alexander Klimov
On Mon, 9 Oct 2006 kkursawe at esat.kuleuven.ac.be wrote:
  IIUC, TPM is pointless for disk crypto: if your laptop is stolen the
  attacker can reflash BIOS and bypass TPM.

 According to TCG Specification, the first part of the BIOS (called
 Core Root of Trust for Measurement) should be non-flashable; this
 part then checksums the rest of the BIOS, option ROMS etc. and
 reports those to the TPM. I don't know how this is done in devices
 currently sold, but at least it should not be trivial to reprogram
 that part of the BIOS.

Even if BIOS is real ROM, but there are some inter-chip links between
ROM, CPU, and TPM, it seems possible for an attacker with an iron and
FPGAs to trick the TPM to reveal the secret. That is against
highly-motivated attacker TPM does not give really more protection
than truecrypt, but for a casual attacker (who is just curious what is
on a stolen laptop) even truecrypt is enough.

-- 
Regards,
ASK

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


RE: TPM disk crypto

2006-10-12 Thread Kuehn, Ulrich
 From: James A. Donald [mailto:[EMAIL PROTECTED] 
 Sent: Dienstag, 10. Oktober 2006 06:40
 
 What we want is that a bank client can prove to the bank it 
 is the real client, and not trojaned.  What the evil guys at 
 RIAA want is that their music player can prove it is their 
 real music player, and not hacked by the end user. Having a 
 system that will only boot up in a known state is going to 
 lead to legions of unhappy customers who find their system 
 does not come up at all.
 

Who is we? In the case of my own system I payed for (so speaking for myself) 
I would like to have such a mechanism to have the system prove to me before 
login that it is not tampered with. The TCG approach does not provide this. Oh, 
and predetermined means that the machine admin can declare to which known state 
the system is going to boot. 

From a company point of view it might be interesting to make sure the 
employees have systems that come up to a predetermined state, or not at all, 
so when infected this turns up at next boot so that the admin can fix it.
Here the TCG approach would also be helpful as the remote attestation against a 
central server (or a number of them) can help. 

And for the RIAA guys, they have no business on the machine I did pay for (!), 
as long as I do not infringe their copyright. Assumed innocent until proven 
guilty! On the other hand, there has been an infamous record company that 
miserably failed  to ensure their components on consumers' computers are _not_ 
a security risk. 

Ulrich

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


Re: TPM disk crypto

2006-10-12 Thread Adam Back
I was suspecting that as DRM at least appears to one of the main
motivators (along side trojan/malware protection) for trustworthy
computing that probably you will not be able to put the TPM into debug
mode (ie manipulate code without affecting the hash attested in debug
mode).  Ability to do so breaks DRM.

Also bear in mind the vista model where it has been described that
inserting an unsigned device driver into the kernel will disable some
media playback (requiring DRM).  And also the secure (encrypted) path
between trusted agent and video/audio card, and between video/audio
card and monitor/speakers.  The HDMI spec has these features, and you
can already buy HDMI cards and monitors (though I dont know if they
have the encryption features implemented/enabled).

I think generally full user control model will not be viewed
compatible.  Ie there will be a direct conflict between user ability
to debug attested apps and DRM.

So then enters the possibility to debug all apps except special ones
flagged as DRM, but if that technical ability is there, you wont have
wait long for it to be used for all things: file formats locked to
editors, per processor encrypted binaries, rented by the hour software
you cant debug or inspect memory space of etc.

I think the current CPUs / memory managers do not have the ring -1 /
curtained memory features, but already a year ago or more Intel and
AMD were talking about these features.  So its possible the for
example hypervisor extra virtualization functionality in recent
processors ties with those features, and is already delivered?  Anyone
know?

The device driver signing thing is clearly bypassable without a TPM,
and we know TPMs are not widely available at present.  (All that is
required is to disable or nop out the driver signature verification in
the OS; or replace the CA or cert it is verified against with your own
and sign your own drivers).  How long until that OS binary patch is
made?

Adam

On Tue, Oct 10, 2006 at 12:56:07PM +0100, Brian Gladman wrote:
 I haven't been keeping up to date with this trusted computing stuff over
 the last two years but when I was last involved it was accepted that it
 was vital that the owner of a machine (not necessarily the user) should
 be able to do the sort of things you suggest and also be able to exert
 ultimate control over how a computing system presents itself to the
 outside world.
 
 Only in this way can we undermine the treacherous computing model of
 trusted machines with untrusted owners and replace it with a model in
 which trust in this machine requires trust in its owner on which real
 information security ultimately depends (I might add that even this
 model has serious potential problems when most machine owners do not
 understand security).
 
 Does anyone know the current state of affairs on this issue within the
 Trusted Computing Group (and the marketed products of its members)?

 Adam Back wrote:
  So the part about being able to detect viruses, trojans and attest
  them between client-server apps that the client and server have a
  mutual interest to secure is fine and good.
  
  The bad part is that the user is not given control to modify the hash
  and attest as if it were the original so that he can insert his own
  code, debug, modify etc.
  
  (All that is needed is a debug option in the BIOS to do this that only
  the user can change, via BIOS setup.)

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


Re: OpenSSL PKCS #7 supports AES SHA-2 ?

2006-10-12 Thread Alex Alten

Russ,

OK.  I found SHA-2 in RFC 4634 (only 3 months old), which refers back to 
FIPS 180-2.


But I reach a dead-end with PKCS #7 (now RFC 3852).  There's no support for 
SHA-2

algorithm types (RFC 3279). Also PKCS #1 (now RFC 3447) needs an update for
SHA-2 with RSA encryption (OIDs, etc.).

Did I miss something or do you need help in updating these, since I, and 
probably

others too, need them?

- Alex


At 01:19 PM 10/9/2006 -0400, Russ Housley wrote:
PKCS#7 has been turned over to the IETF for maintenance.  The most recent 
version is RFC 3852.  Since the protocol is more stable than the 
cryptographic algorithms, the algorithm discussion appear in separate RFCs.


TLS 1.2 is under development in the IETF.  It is being done in such a way 
that none of the ciphersuites that have already been defined need to be 
updated, including the ones that use AES and the SHA-2 family.


Russ


At 01:28 AM 10/7/2006, Alex Alten wrote:

After reading PKCS #1 v2 more closely and SHA-2 is not even in the specs,
therefore OpenSSL PKCS #7 functions won't support SHA-2.  This spec was
last updated in 1998.

PKCS Editor, is there a new update in progress by RSA Labs to incorporate
SHA-2 and AES?

Does OpenSSL implement PKCS #1 v2 or just v1.5?  If the latter then not even
SHA-1 is supported.

PKCS editor, is there any timeline as to when PKCS #7 will then be updated
with references to official OIDs, etc., for specifying SHA-2 and AES?

Dr. Ron Rivest, are you going to publish new message-digest IETF RFCs for 
SHA-1

and SHA-2?  (So that they can be referenced by an updated PKCS #7.)

Mr. Russ Housley, can you weigh in with what happening in the IETF WG 
security
area?  I know that Mr. Eric Rescorla is working on a new TLS v1.2 
draft.  Will this
be done/ratified soon?  I assume OpenSSL will incorporate this soon 
thereafter?


This mess with the MD5 and SHA-1 hashes is really starting to becoming a 
problem.
It's certainly impacting new development projects/products I'm involved 
with using

SSL and PKI certificates.  My customers are concerned about using MD5 and
SHA-1, and they don't want to keep paying for implementations repeatedly 
as the

standards catch up to reality.  Updating these various heavily used standards
quickly is quite important.

Sincerely (and thanks in advance for all of your replies),

- Alex


At 09:05 AM 10/6/2006 -0700, Alex Alten wrote:

Does anyone know if the OpenSSL PKCS #7 functions support AES and SHA-2?
(I assuming OpenSSL 0.9.7 or later.)

Thanks,

- Alex


--

Alex Alten
Alten Security Engineering, Inc.
[EMAIL PROTECTED]




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


Re: TPM disk crypto

2006-10-12 Thread Alexander Klimov
On Mon, 9 Oct 2006, James A. Donald wrote:

 Well obviously I trust myself, and do not trust anyone else all that
 much, so if I am the user, what good is trusted computing?

 One use is that I can know that my operating system has not changed
 behind the scenes, perhaps by a rootkit, know that not only have I
 not changed the operating system, but no one else has changed the
 operating system.

The argument that TPM can prevent trojans seems to imply that the
trojans are installed by modification of raw storage while the OS is
offline. Probably, this can be a case for malicious internet-cafes,
but 99.9% of trojans on home PCs of normal people are installed when
the OS is active (0.1% is for trojans installed by law enforcement).
(Of course, an attacker with physical access can install physical
trojans: hardware keylogger and camera.) Since a regular installation
should not change ``reported OS hash,'' TPM will not be able to detect
the difference. Am I missing something?

Btw, how the TCG allows to regularly change the kernel for security
patches and still keep the same ``reported hash''?

-- 
Regards,
ASK

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


Re: TPM disk crypto

2006-10-12 Thread John Gilmore
 What we want is that a bank client can prove to the bank
 it is the real client, and not trojaned.  What the evil
 guys at RIAA want is that their music player can prove
 it is their real music player, and not hacked by the end
 user. Having a system that will only boot up in a known
 state is going to lead to legions of unhappy customers
 who find their system does not come up at all.

Having remote attestation that provides signed checksums of every
stage of the startup process, which are checked by guys at the RIAA or
guys at the bank, will lead to legions of unhappy customers who find
their system boots fine, but is denied access to both the bank and the
music store.  (Seventy thousand totally valid configurations are not
going to be checked and confirmed by either one.)  But their system
will access the Darknet just fine.

John

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


Re: TPM disk crypto

2006-10-12 Thread Travis H.

On 10/9/06, Adam Back [EMAIL PROTECTED] wrote:

The bad part is that the user is not given control to modify the hash
and attest as if it were the original so that he can insert his own
code, debug, modify etc.

(All that is needed is a debug option in the BIOS to do this that only
the user can change, via BIOS setup.)


Actually, it's the BIOS I don't trust.

I can validate everything else, but as long as the BIOS is
motherboard-specific and closed source, I don't see why I should trust
it.  We need to get rid of this legacy crud.  LinuxBIOS is a good step
but unfortunately it is only supported on a few motherboards.  No BIOS
I know of has a semblance of security, given temporary physical access
to the machine.

BTW, the x86 microcode updates are performed by the BIOS IIRC and
require no hardware settings.  Is there any reason you can't update
the processor microcode later on in the boot process?
--
The obvious mathematical breakthrough would be the development of an
easy way to factor large prime numbers.'' [sic] -- Bill Gates  --
URL:http://www.lightconsulting.com/~travis/
GPG fingerprint: 9D3F 395A DAC5 5CCC 9066  151D 0A6B 4098 0C55 1484

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


Re: TPM disk crypto

2006-10-12 Thread cyphrpunk

On 10/10/06, Brian Gladman [EMAIL PROTECTED] wrote:

I haven't been keeping up to date with this trusted computing stuff over
the last two years but when I was last involved it was accepted that it
was vital that the owner of a machine (not necessarily the user) should
be able to do the sort of things you suggest and also be able to exert
ultimate control over how a computing system presents itself to the
outside world.

Only in this way can we undermine the treacherous computing model of
trusted machines with untrusted owners and replace it with a model in
which trust in this machine requires trust in its owner on which real
information security ultimately depends (I might add that even this
model has serious potential problems when most machine owners do not
understand security).

Does anyone know the current state of affairs on this issue within the
Trusted Computing Group (and the marketed products of its members)?


1. The issue is still moot at present. We are a long way from where
open, public, remote attestion will be possible. See this diagram from
the Trousers open-source TPM software stack project which shows which
pieces are still missing:

http://trousers.sourceforge.net/remote_attestation_deps.png

There is actually another important piece missing from that diagram,
namely operating system support. At present the infrastructure would
only allow attestation at the OS-boot level, i.e. you could prove what
OS you booted. It's a big step from there to proving that you are
running a safe application, unless the service would require you to
reboot your machine into their OS every time you want to run their
client.

2. Not an insider, but I haven't heard anything about serious efforts
to implement Owner Override or similar proposals. Instead, the
response seems to be to wait and hope all that fuss blows over.

3. What little evidence exists suggests that TCG is going in the
opposite direction. The 1.2 TPM is designed to work with Intel's
Lagrange Technology which will add improved process isolation and late
launch. This will make it possible to attest at the level of
individual applications, and provide protection against the local user
that a plain TPM system can't manage. 1.2 also adds a
cryptographically blinded attestation mode that gets rid of the ugly
privacy ca which acted as a TTP in 1.1, and which will make it
easier to move towards attestation.

4. Software remains the biggest question mark, and by software I mean
Microsoft. They have said nothing about attestation support in Vista.
Given the hostile response to Palladium I doubt there is much
enthusiasm about jumping back into that crocodile pit. It doesn't seem
to be stopping HD-DVD from moving forward, even though there is no
credible probability of an attestation feature appearing in the time
frame needed for these new video product introductions.

Without a driving market force to introduce attestation, and
tremendous social resistance, the status quo will probably prevail for
another couple of years. By that time LT will be available, TPMs will
be nearly universal but used only for improved local security, and
perhaps some tentative steps into attestation will appear. The initial
version might be targeted at corporate VPNs which will prevent mobile
employees from connecting unless their laptops attest as clean. This
would be an uncontroversial use of the technology except for its
possible implications as a first step towards wider use.

Whether we will eventually ever see the whole model, with attestation,
process isolation, sealed storage, and trusted i/o path all leading to
super-DRM, is very much an open question. So many barriers exist
between here and there that it seems unlikely that this will be seen
by anyone as the right solution to that problem, by then.

CP

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


RE: OpenSSL PKCS #7 supports AES SHA-2 ?

2006-10-12 Thread Whyte, William
PKCS#7 has been superseded by the IETF's Cryptographic Message Syntax, CMS.
You should check within the S/MIME working group for updates.

William 

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of Alex Alten
 Sent: Saturday, October 07, 2006 12:29 AM
 To: cryptography@metzdowd.com
 Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; 
 [EMAIL PROTECTED]; [EMAIL PROTECTED]; 
 [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; 
 [EMAIL PROTECTED]; [EMAIL PROTECTED]
 Subject: Re: OpenSSL PKCS #7 supports AES  SHA-2 ?
 
 After reading PKCS #1 v2 more closely and SHA-2 is not even 
 in the specs,
 therefore OpenSSL PKCS #7 functions won't support SHA-2.  
 This spec was
 last updated in 1998.
 
 PKCS Editor, is there a new update in progress by RSA Labs to 
 incorporate
 SHA-2 and AES?
 
 Does OpenSSL implement PKCS #1 v2 or just v1.5?  If the 
 latter then not even
 SHA-1 is supported.
 
 PKCS editor, is there any timeline as to when PKCS #7 will 
 then be updated
 with references to official OIDs, etc., for specifying SHA-2 and AES?
 
 Dr. Ron Rivest, are you going to publish new message-digest 
 IETF RFCs for 
 SHA-1
 and SHA-2?  (So that they can be referenced by an updated PKCS #7.)
 
 Mr. Russ Housley, can you weigh in with what happening in the 
 IETF WG security
 area?  I know that Mr. Eric Rescorla is working on a new TLS v1.2 
 draft.  Will this
 be done/ratified soon?  I assume OpenSSL will incorporate 
 this soon thereafter?
 
 This mess with the MD5 and SHA-1 hashes is really starting to 
 becoming a 
 problem.
 It's certainly impacting new development projects/products 
 I'm involved 
 with using
 SSL and PKI certificates.  My customers are concerned about 
 using MD5 and
 SHA-1, and they don't want to keep paying for implementations 
 repeatedly as 
 the
 standards catch up to reality.  Updating these various 
 heavily used standards
 quickly is quite important.
 
 Sincerely (and thanks in advance for all of your replies),
 
 - Alex
 
 
 At 09:05 AM 10/6/2006 -0700, Alex Alten wrote:
 Does anyone know if the OpenSSL PKCS #7 functions support 
 AES and SHA-2?
 (I assuming OpenSSL 0.9.7 or later.)
 
 Thanks,
 
 - Alex
 
 
 -
 The Cryptography Mailing List
 Unsubscribe by sending unsubscribe cryptography to 
 [EMAIL PROTECTED]
 

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


Government crypto?

2006-10-12 Thread Steven M. Bellovin
http://www.theonion.com/content/node/53928

--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

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