Re: delegating SSL certificates
| Presumably the value they add is that they keep browsers from popping | up scary warning messages Apple's Mail.app checks certs on SSL-based mail server connections. It has the good - but also bad - feature that it *always* asks for user approval if it gets a cert it doesn't like. Good point -- other mail programs such as Thunderbird also pop up the scary warnings. I've paid the $15 protection money for the certs on my mail servers. R's, John - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
NSA approves secure smart phone
http://www.gcn.com/online/vol1_no1/45946-1.html --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: delegating SSL certificates
On Mar 16, 2008, at 8:50 AM, John Levine wrote: So at the company I work for, most of the internal systems have expired SSL certs, or self-signed certs. Obviously this is bad. You only think this is bad because you believe CAs add some value. Presumably the value they add is that they keep browsers from popping up scary warning messages. There are all sorts of reasonable arguments to be made that the browsers are doing the wrong thing (and the way that Microsoft prevents you from ever deleting any of their preinstalled CA certs is among the wrongest.) Yes, but. If a browser handled unknown certificates similarly to the way SSH does -- to alert the user when it sees an unknown, unrooted certificate, and then only again when there is a mis-match, you would have an incentive to get a CA certificate (because businesses don't want their customers to see that scary message even once), while supporting ad-hoc infrastructures. This would require only software changes, not changes in the trust models, CAs, procedures, etc. A wicked person would suggest that this is because the present system was designed to support the business model, not the security model. I'm not a wicked person and would never suggest that. Jon - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: delegating SSL certificates
[EMAIL PROTECTED] (Peter Gutmann) on Sunday, March 16, 2008 wrote: [EMAIL PROTECTED] writes: I would think this would be rather common, and I may have heard about certs that had authority to sign other certs in some circumstances... The desire to do it isn't uncommon, but it runs into problems with PKI religious dogma that only a CA can ever issue a certificate. Is that a religious dogma, or a business model masquerading as a religious dogma? Whichever it is, it is an impediment to improving protection against fishing attacks. Consider a large organization like Amazon and users using tools like the Petname toolbar http://www.waterken.com/dev/YURL/Name/. Amazon has many servers, each of which needs a TLS signing key. In a more ideal world, Amazon would have a CA signed public certification key, which it would use to certify each server's TLS signing key. The Petname toolbar would use Amazon's public certification key as the identity matching the user's petname for Amazon. Once that petname has been established, AKA the introduction problem, the identity would be safe, regardless of what happens higher in the PKI hierarchy. The higher levels of the PKI hierarchy would only be used during the introductory contact. Given the current situation, with the CAs having a monopoly on issuing certificates, there are many different public keys associated with Amazon. In addition, Amazon may chose to change the CA it uses. To handle this situation, the Petname toolbar the DN instead of a public key, which opens the Petname tool bar to spoofing by any of the 100 or so CAs configured in the standard browsers. Does anyone know what happened to Baltimore's signing key when they went out of business? 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]
Firewire threat to FDE
Hello, As if the latest research (which showed that RAM contents can be recovered after power-down) was not enough, it seems as Firewire ports can form yet an easier attack vector into FDE-locked laptops. Windows hacked in seconds via Firewire http://www.techworld.com/security/news/index.cfm?RSSNewsID=11615 The attack takes advantage of the fact that Firewire can directly read and write to a system's memory, adding extra speed to data transfer. IIUC, the tool mentioned only bypasses the Win32 unlock screen, but given the free access to RAM, exploit code that digs out FDE keys is a matter of very little extra work. This is nothing new. The concept was presented a couple of years ago, but I haven't seen most FDE enthusiasts disable their Firewire ports yet. Unsurprisingly: Microsoft downplayed the problem, noting that the Firewire attack is just one of many that could be carried out if an attacker already has physical access to the system. The claims [...] are not software vulnerabilities, but reflect a hardware design industry issue that affects multiple operating systems, Bill Sisk, Microsoft's security response communications manager, told Techworld. It is not *their* fault, but being a company that pretends to take users' security seriously, and being at a position that allows them to block this attack vector elegantly, I would have gone that extra half-mile rather than come up with excuses why not to fix it. All they need to do is make sure (through a user-controlled but default-on feature) that when the workstation is locked, new Firewire or PCMCIA devices cannot be introduced. That hard? Hagai. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Protection for quasi-offline memory nabbing
Such as Cold Boot, etc. There have been a number of conversations among my colleagues on how to ameliorate this, particularly with an eye to making suspend mode safer. In the Cold Boot paper, the authors suggested XORing a piece of random memory onto the dangerous bits, so as to fuzz them. This is a clever idea, but we didn't like it, particularly because XOR doesn't have the best diffusion in the world. The solution we came up with is to use EME mode (or equivalent) with a fixed key. The outline is that you encrypt all dangerous data, like volume key, key expansion, etc, with a fixed key into a chunk that you keep to the side. This relies upon the property of EME (and other large-block, tweakable modes) that a single-bit error in the ciphertext propagates to an error in the entire plaintext. Consequently, a very low rate of memory decay turns into complete protection of that sensitive data. Upon suspend, you erase and deallocate the active store, and on wake you decrypt the fuzzed copy to get your keys and state variables back. If you want to one-plus this, you could have a timeout on the drive so that if it's idle for N seconds, you do same. When we came up with this, we wondered if it was patentable. We've decided that it isn't, that this is something that is obvious to someone skilled in the art. Our reasoning is something like: Cold Boot paper suggests XORing random memory but -- XOR has cruddy diffusion What has better diffusion? (discard suggestions like lead, churches, and very small rocks) Block ciphers have great diffusion but -- block ciphers operate on only a small chunk What operates like a block cipher on a large chunk? Tweakable modes like EME. QED The rest is just software engineering. The cool thing about using EME (or equivalent) is that the larger the chunk you create, the better you survive a Cold Boot attack. Note, however, that an attacker who can grab memory with no errors in it, such as someone who is playing DMA games, still gets the keys. To protect against that, you have to have an authentication mechanism, which is outside the scope of this -- we want something that is transparent, but can make people worry less about suspending their laptop. Also note that you don't really need a full cipher. All you need is reversible diffusion that maximizes damage on a single-bit error. However, the danger in coming up with another function is that you're effectively designing special-purpose crypto. Yes, it's really special- purpose coding, not crypto, but it's a lot safer to use crypto. We understand it better. A number of people participated in our discussions and at least two people independently thought of the core idea. The people include but are not limited to (which means I apologize to everyone I forgot): Colin Plumb, Phil Zimmermann, Hal Finney, Andrey Jivsov, Will Price, David Finkelstein, and Bill Zhao. Jon - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Firewire threat to FDE
| As if the latest research (which showed that RAM contents can be | recovered after power-down) was not enough, it seems as Firewire ports | can form yet an easier attack vector into FDE-locked laptops. | | Windows hacked in seconds via Firewire | http://www.techworld.com/security/news/index.cfm?RSSNewsID=11615 | | The attack takes advantage of the fact that Firewire can | directly read and write to a system's memory, adding extra speed | to data transfer | | IIUC, the tool mentioned only bypasses the Win32 unlock screen, but | given the free access to RAM, exploit code that digs out FDE keys is a | matter of very little extra work. | | This is nothing new. The concept was presented a couple of years ago, | but I haven't seen most FDE enthusiasts disable their Firewire ports | yet. | | Unsurprisingly: | | Microsoft downplayed the problem, noting that the Firewire | attack is just one of many that could be carried out if an | attacker already has physical access to the system. | | The claims [...] are not software vulnerabilities, | but reflect a hardware design industry issue that affects | multiple operating systems, Bill Sisk, Microsoft's security | response communications manager, told Techworld. | | It is not *their* fault, but being a company that pretends to take | users' security seriously, and being at a position that allows them to | block this attack vector elegantly, I would have gone that extra | half-mile rather than come up with excuses why not to fix it. All they | need to do is make sure (through a user-controlled but default-on | feature) that when the workstation is locked, new Firewire or PCMCIA | devices cannot be introduced. That hard? Just how would that help? As I understand it, Firewire and PCMCIA provide a way for a device to access memory directly. The OS doesn't have to do anything - in fact, it *can't* do anything. Once your attacker is on the bus with the ability to do read/write cycles to memory, it's a bit late to start worrying about whether you allow that device to be visible through the OS. Note that disks have always had direct access to memory - DMA is the way to get acceptable performance. SATA ports - uncommon on portables, very common on servers - would be just as much of a threat. Same for SCSI on older machines. Normally, the CPU sets up DMA transfers - but it's up to the device to follow the rules and not speak until recognized. But there's no real enforcement. (Oh, if you start talking out of turn, you might hang the bus or crash the system if you collide with something - but that's like very rare, and hardly an effective protective measure.) The only possible protection here is at the hardware level: The external interface controller must be able to run in a mode which blocks externally-initiated memory transactions. Unfortunately, that may not be possible for some controllers. Sure, the rules for (say) SCSI might say that a target is only supposed to begin sending after a request from an initiator - but it would take a rather sophisticated state machine to make sure to match things up properly, especially on a multi-point bus. -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: delegating SSL certificates
John Levine wrote: | Presumably the value they add is that they keep browsers from popping | up scary warning messages Apple's Mail.app checks certs on SSL-based mail server connections. It has the good - but also bad - feature that it *always* asks for user approval if it gets a cert it doesn't like. Good point -- other mail programs such as Thunderbird also pop up the scary warnings. I've paid the $15 protection money for the certs on my mail servers. I have found that just adding the cert to the local keystore had pretty much the same effect. There is a nice addon for Thunderbird/Firefox (which will apparently be a native ability in v3 of the latter) called remember mismatched domains that lets you suppress an error for a specific cert/domain mismatch. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
