Re: handling weak keys using random selection and CSPRNGs
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
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
> 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
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 ?
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
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
> 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
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 -><- 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
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 ?
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?
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]
