Re: disks with hardware FDE
On Tue, 8 Jul 2008, Perry E. Metzger wrote: | Has anyone had any real-world experience with these yet? Are there | standards for how they get the keys from the BIOS or OS? (I'm | interested in how they deal with zeroization on sleep and such.) | | Most manufacturer (will) implement the TCG Storage Specification: | https://www.trustedcomputinggroup.org/groups/storage/ | | Lastly, anyone have any idea of whether the manufacturers are doing | the encryption correctly or not? | | I know that Seagate Secure does not use XTS mode, but something CBC | based. | | Where do they get their IVs from? I have no idea what they actually *do*, but the obvious way to get an IV is to use the encryption of the block number. Guaranteed known to whoever needs to decrypt the disk block, and unique for each disk block. (Using the disk block number itself as the IV is actually reasonably safe, too, though it seems a bit too structured - one can imagine files which have a leading count or even a copy of the disk block number in each disk block leading to an initial zero input to the encryption.) (I think one of Phil Rogoway's papers suggest this kind of approach for a safe CBC API: Given an existing CBC API that takes an IP as input, instead build one that takes no explicit IP, but (a) maintains an internal counter; (b) prepends the current counter value to the supplied input and increments the counter; (c) supplies the underlying API with an IP of 0. The modified API can't be abused by accidentally re-using an IP.) | In general, I feel like the only way to really verify that these | things are being done correctly is to be able (in software) to read | the ciphertext and verify that it is encrypted with the right key in | the right mode. The small amount I've heard about the design leads me | to worry that this is not actually possible. Somehow we still haven't learned the lesson that the security can only come from (a) published, vetted algorithms and modes; (b) a way to check that the alleged algorithm is what the black box actually implements. Of course, for all you know it implements the algorithm while hiding a copy of the key away somewhere just in case But that's a whole other problem. -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Strength in Complexity?
Ben Laurie wrote: OK, so you still have a PKI problem, in that you have to issue and manage client certificates. How is this done? One man's meat :-). (I don't necessarily view this as a problem Ben. I've built up a career and a small business in the last 9 years doing just that.) Nevertheless, to answer the question, the PKI deployment is not part of the SKSML prtocol (other than the WSS header that carries the XML Signature and/or XML Encryption of the SOAP Body), but it is part of an EKMI. (EKMI = PKI + SKMS). A company deploying an EKMI must have, or must build a PKI and deploy the client/server certificates separately from the SKMS. While this might be viewed as a problem for some/many companies in the short-term, I fully anticipate that vendor implementations of SKMS will integrate with PKI software to manage this process seamlessly in the future. I do not believe this is the case. DRM fails because the attacker has physical possession of the system he is attacking. Which is why we are recommending that SKMS clients use hardware based modules (be it TPMs, smartcards, HSMs, etc.) to generate and store the Private Key used by SKMS client to decrypt the symmetric keys. While even these can be attacked, the problem is now in a different domain than the SKSML protocol. EKMI's goals are not to provide bullet-proof security. It has more modest ambitions - to provide a management framework for incremental security, targeted at the right resource: the data, rather than the network. Are there any even vaguely modern systems that target the network for security, or is this a straw man? What I meant to say is that EKMI's goal is to protect the data and not the network. If it is up to them, then why bother with this verification process? This sounds like yet more security theatre to me. I'm not sure which verification process you're referring to. No, this is not security theater. EKMI does not guarantee anything, nor does it promise unbreakable anything. Everything in EKMI is a choice. You get to choose the strength of your keys, your PKI, your policies, your procedures and your implementation. All we're offering is a tool that does something specific to the extent that the specifications and the technology allows. Nothing more, nothing less. If you - as a cryptographer - say that AES-156 will do X under these conditions, then EKMI will support X under those conditions. EKMI only adds the ability to manage a large number of keys centrally, and to ease many of the administrative burdens we see that large-scale key-management can cause. Everything it does is constrained by the limitations of the underlying technology components, polices and practices. But you still have to make the choice. Arshad Noor StrongAuth, Inc. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Permanent Privacy - Are Snake Oil Patents a threat?
Ali, Saqib wrote: Quoting the Foxbusiness article: Permanent Privacy (patent pending) has been verified by Peter Schweitzer, one of Harvard's top cryptanalysts, and for the inevitable cynics Permanent Privacy is offering $1,000,000 to anyone who can decipher a sample of ciphertext. I did a quick check to look for patent applications or patents by them and didn't find any. This isn't definitive if a patent application isn't published. The newest published patent application I found on encryption had an application date of 11 Dec 2007. Some recently published patent applications are 6 or 7 years old, too. While there I updated my periodic search for recent patents and applications on cryptography. It's surprising the number of questionable patent applications and patents you can find. Aside from propping up marketing claims with patents as has been done throughout history, the primary threat poor quality patents present is the ability of patent trolls to tax 'innovation'. The volume of crypto related patents and applications is increasing lately and there is no clear sign the quality is rising. Crypto patents used to be primarily a competition method between defense contractors, now its just about everyone as use expands. There was one recent application from a chip company on an architecture and instruction set for implementing the Advanced Encryption Standard , where the architecture is that of a modern processor and the instruction set isn't covered in the claims, rather a description of the algorithm for executing AES is given. While it would be well suited for a defensive patent portfolio, imagine the havoc if granted and this patent were to fall into the hands of a patent troll claiming it covered all implementations on a processor. Being a bit of a hardware wonk, a lot of these patents appear obvious. For instance Rainbow inherited a patent on the use of dual rank shift registers to allow overlapping data I/O and cryptographic operations. It does perform the useful function of bringing down the clock rate needed to sustain some throughput, but it was hardly a non-obvious innovation at the time it was filed. Rate buffers had been used as long before the patent was filed to balance communications throughput. I also recall one on MIMD execution of DES to increase throughput, hardly non-obvious though granted. Obviously patents could be improved by searching further across disciplines for prior art and by having more USPTO expertise. We're also seeing a dumbing down of the 'Persons Having Ordinary Skill In the Art' as the number of practitioners expand rapidly. Has anyone been feeling the heat or see a future threat? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Kaminsky finds DNS exploit
I think Dan Kaminsky is on this list. Any other tidbits you can add prior to Black Hat? Udhay http://www.liquidmatrix.org/blog/2008/07/08/kaminsky-breaks-dns/ Kaminsky Breaks DNS Author: Dave Lewis July 8, 2008 at 2:21 pm · Filed under Patches, Vulnerability Well, sort of. Today Dan Kaminsky released a first, as far as I can recall. A coordinated patch was released today by Dan Kaminsky of IO Active that fixes a vulnerability that apparently exists in all DNS servers. Unlike other researchers who give up the gory details, Kaminsky took a wiser path by smiling and nodding. He’ll give up the goods at Black Hat in August. That should give folks enough time to patch their systems. snip -- ((Udhay Shankar N)) ((udhay @ pobox.com)) ((www.digeratus.com)) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: disks with hardware FDE
Arshad Noor [EMAIL PROTECTED] writes: Perry E. Metzger wrote: There are now a number of drives on the market advertising AES based FDE in hardware, and a number of laptops available on the market that claim to support them. [...] There is a debate going on on that list about the value of encrypting data at the disk-drive layer vs. encrypting at the application layer - I believe the latter is a more strategic solution - and the voices from the Crypto forum would be welcome on these issues. One thing about drive-based encryption is that we're been proised this since about 2000 or 2001, and it's always just another year or two away for various reasons: standardisation, host controller support, OS support, phase of the moon, ... . The current reason seems to be FIPS 140: the turnaround time for a FIPS 140 eval is significantly longer than the mean lifetime of any particular hardware/firmware config, and the cost of the constant re-evals doesn't help much either. So drive-based FDE is currently awaiting the loading of a compliment of small FIPS 140-soaked paper napkins. Until then there will be a short delay. Please return to your seats. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
I don't trust FDE drives.
I've now talked to a few people affiliated with drive companies at this point. One of them seems to really know what he's doing. The rest appear not to. One has even spoken to me of keying material being protected by what are effectively one time pads and trust us, this is our business in ways that make me not trust him, or his company, at all. Based on what I've heard, I suspect that a grad student who wants a *really* good paper could probably manage to humiliate a couple of drive companies with a little bit of effort. It is likely to get you plenty of publicity. Also, at this point, I'm not sure one should trust FDE drives with data that one really cares about. Software based solutions can be much more readily analyzed and verified. They require much less trust that a vendor has done their job right. I don't think one can trust the hard drive vendors. Perry -- Perry E. Metzger[EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Kaminsky finds DNS exploit
On Wed, 09 Jul 2008 11:22:58 +0530 Udhay Shankar N [EMAIL PROTECTED] wrote: I think Dan Kaminsky is on this list. Any other tidbits you can add prior to Black Hat? Udhay http://www.liquidmatrix.org/blog/2008/07/08/kaminsky-breaks-dns/ I'm curious about the details of the attack. Paul Vixie published the basic idea in 1995 at Usenix Security (http://www.usenix.org/publications/library/proceedings/security95/vixie.html) -- in a section titled What We Cannot Fix, he wrote: With only 16 bits worth of query ID and 16 bits worth of UDP port number, it's hard not to be predictable. A determined attacker can try all the numbers in a very short time and can use patterns derived from examination of the freely available BIND code. Even if we had a white noise generator to help randomize our numbers, it's just too easy to try them all. Obligatory crypto: the ISC web page on the attack notes DNSSEC is the only definitive solution for this issue. Understanding that immediate DNSSEC deployment is not a realistic expectation... --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Kaminsky finds DNS exploit
First off, big props to Dan for getting this problem fixed in a responsible manner. If there were widespread real attacks first, it would take forever to get fixes out into the field. However, we in the security circles don't need to spread the Kaminsky finds meme. Take a look at http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-forgery-resilience/. The first draft of this openly-published document was in January 2007. It is now in WG last call. The take-away here is not that Dan didn't discover the problem, but Dan got it fixed. An alternate take-away is that IETF BCPs don't make nearly as much difference as a diligent security expert with a good name. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Kaminsky finds DNS exploit
However, we in the security circles don't need to spread the Kaminsky finds meme. Quite right. Paul Vixie mentioned it in 1995, Dan Bernstein started distributing versions of dnscache with randomized port and sequence numbers in 2001. The take-away here is not that Dan didn't discover the problem, but Dan got it fixed. An alternate take-away is that IETF BCPs don't make nearly as much difference as a diligent security expert with a good name. I suppose 13 years is kind of a long time, but better late than never. It would be modestly interesting to learn what is different now that motivated him to get people to fix it. R's, John - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Permanent Privacy - Are Snake Oil Patents a threat?
| ...Obviously patents could be improved by searching further across | disciplines for prior art and by having more USPTO expertise. We're | also seeing a dumbing down of the 'Persons Having Ordinary Skill In | the Art' as the number of practitioners expand rapidly. Patent law and its interpretation - like all law - changes over time. Through much of the early twentieth century, patent law was strongly biased in favor of large companies. A small inventor couldn't get any effective quick relief against even obvious infringements - he had to fight a long, drawn-out battle, at the end of which he probably didn't end up with much anyway. In reaction to such famous cases as the much-infringed patent on FM radio, the law was changed and reinterpreted in ways that gave the small inventor much more power. Unfortunately, patent trolls eventually made use of those same changes The last couple of decades have seen a series of cases that effectively gutted the entire notion of obvious to persons having ordinary skills in the art. As often happens with trends like this, if you look back at the early cases that started the trend, the results may seem reasonable - but over time, the whole thing gets out of control. The Supreme Court, in a decision last year (the name and details of which escape me), pretty much said This has gone too far. Specific- ally, they said that applying a technique that is well known in one area to another area may well be obvious and not eligible for patent protection. The Supreme Court can only decide on cases brought before it, but the feeling seems to be that they are signaling a readiness to breath new life into the non-obviousness requirement for a patent. It'll be years before we see exactly how this all settles out. -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Kaminsky finds DNS exploit
Paul Hoffman wrote: First off, big props to Dan for getting this problem fixed in a responsible manner. If there were widespread real attacks first, it would take forever to get fixes out into the field. However, we in the security circles don't need to spread the Kaminsky finds meme. Take a look at http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-forgery-resilience/. The first draft of this openly-published document was in January 2007. It is now in WG last call. The take-away here is not that Dan didn't discover the problem, but Dan got it fixed. An alternate take-away is that IETF BCPs don't make nearly as much difference as a diligent security expert with a good name. Guess you need to tell Dan that - he seems to think he did discover it. -- http://www.apache-ssl.org/ben.html http://www.links.org/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Kaminsky finds DNS exploit
On Wed, Jul 09, 2008 at 08:20:33AM -0700, Paul Hoffman wrote: First off, big props to Dan for getting this problem fixed in a responsible manner. If there were widespread real attacks first, it would take forever to get fixes out into the field. However, we in the security circles don't need to spread the Kaminsky finds meme. Take a look at http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-forgery-resilience/. The first draft of this openly-published document was in January 2007. It is now in WG last call. The take-away here is not that Dan didn't discover the problem, but Dan got it fixed. An alternate take-away is that IETF BCPs don't make nearly as much difference as a diligent security expert with a good name. The discovery is almost certainly a generalization of: http://tools.ietf.org/html/draft-ietf-dnsext-forgery-resilience-05#section-4.3 specifically the second paragraph the mentions the Birthday Attack. The assumptions of that paragraph can be relaxed in a natural way to broaden the scope of the attack. -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Kaminsky finds DNS exploit
On Wed, Jul 09, 2008 at 05:36:02PM +0100, Ben Laurie wrote: Paul Hoffman wrote: First off, big props to Dan for getting this problem fixed in a responsible manner. If there were widespread real attacks first, it would take forever to get fixes out into the field. However, we in the security circles don't need to spread the Kaminsky finds meme. Take a look at http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-forgery-resilience/. The first draft of this openly-published document was in January 2007. It is now in WG last call. The take-away here is not that Dan didn't discover the problem, but Dan got it fixed. An alternate take-away is that IETF BCPs don't make nearly as much difference as a diligent security expert with a good name. Guess you need to tell Dan that - he seems to think he did discover it. Taking a brief look at what changed in bind, it seems primarily to involve randomizing the query port, matching both the port and transaction id instead of just the id, and using RC4 to generate the transactions ids instead of a pair of very sketchy-looking (cryptographically speaking) RNGs based on an LCRNG design via Knuth. Perhaps there is something subtle here that is more dangerous than the well known problems, and all these source port randomization and transaction id randomization fixes are just a smokescreen of sorts for a fix for something Dan found. Securosis claims [1] The good news is that due to the nature of this problem, it is extremely difficult to determine the vulnerability merely by analyzing the patches, and Dan claims something similar, offering to share the stage at Defcon with anyone who finds the bug [2] A statement from the MaraDNS author [3]: MaraDNS is immune to the new cache poisoning attack. MaraDNS has always been immune to this attack. Ditto with Deadwood (indeed, people can use MaraDNS or Deadwood on the loopback interface to protect their machines from this attack). OK, basically, this is an old problem DJB wrote about well over seven years ago. The solution is to randomize both the query ID and the source port; MaraDNS/Deadwood do this (and have been doing this since around the time of their first public releases that could resolve DNS queries) using a cryptographically strong random number generator (MaraDNS uses an AES variant; Deadwood uses the 32-bit version of Radio Gatun). (But CERT has no reply in their advisory from MaraDNS, so I'm not sure if this statement was made on the basis of just what is publically known, or if he was in fact in on the vendor notify list). -Jack [1] http://securosis.com/2008/07/08/dan-kaminsky-discovers-fundamental-issue-in-dns-massive-multivendor-patch-released/ [2] http://www.doxpara.com/?p=1162 [3] http://marc.info/?l=maradns-listm=121560639013865w=2 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Kaminsky finds DNS exploit
Ben Laurie wrote: Paul Hoffman wrote: First off, big props to Dan for getting this problem fixed in a responsible manner. If there were widespread real attacks first, it would take forever to get fixes out into the field. However, we in the security circles don't need to spread the Kaminsky finds meme. Take a look at http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-forgery-resilience/. The first draft of this openly-published document was in January 2007. It is now in WG last call. The take-away here is not that Dan didn't discover the problem, but Dan got it fixed. An alternate take-away is that IETF BCPs don't make nearly as much difference as a diligent security expert with a good name. Guess you need to tell Dan that - he seems to think he did discover it. Well, he does seem to credit quite a few people and companies on his own blog entry about the matter: http://www.doxpara.com/?p=1162 It does seem he would like an air of some mystery to exist though until he makes his presentation about the issue at Defcon - did he, himself, discover something new? We'll just have to wait, unless we go play with the BIND code ourselves. Regards, - johnk - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Kaminsky finds DNS exploit
+ John Kemp [EMAIL PROTECTED]: It does seem he would like an air of some mystery to exist though until he makes his presentation about the issue at Defcon - did he, himself, discover something new? We'll just have to wait, unless we go play with the BIND code ourselves. Unless he is merely blowing smoke, it would seem that he discovered some little twist that makes the known vulnerability much more easily exploitable than previously assumed. That would explain his statement: the patch fixes a well known vulnerability, and as a side effect stops the more serious attack, in effect making it hard to tell what is involved in that attack from reading the patch. - Harald - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Kaminsky finds DNS exploit
Steven M. Bellovin wrote: On Wed, 09 Jul 2008 11:22:58 +0530 Udhay Shankar N [EMAIL PROTECTED] wrote: I think Dan Kaminsky is on this list. Any other tidbits you can add prior to Black Hat? Udhay http://www.liquidmatrix.org/blog/2008/07/08/kaminsky-breaks-dns/ I'm curious about the details of the attack. Paul Vixie published the basic idea in 1995 at Usenix Security (http://www.usenix.org/publications/library/proceedings/security95/vixie.html) -- in a section titled What We Cannot Fix, he wrote: With only 16 bits worth of query ID and 16 bits worth of UDP port number, it's hard not to be predictable. A determined attacker can try all the numbers in a very short time and can use patterns derived from examination of the freely available BIND code. Even if we had a white noise generator to help randomize our numbers, it's just too easy to try them all. So this seems to me to only be really true in a theoretical sense. Exploring the whole 32 bit space obviously requires well in excess of 4 GB of traffic, which is clearly a non-trivial amount to dump on your victim. According to other data, the fix in BIND is to: a) use random ports b) use a good PRNG so I'm beginning to suspect the issue is simply that the theory that it was easy to attack led to no effort being made to make it as hard as possible. And now it has. Obligatory crypto: the ISC web page on the attack notes DNSSEC is the only definitive solution for this issue. Understanding that immediate DNSSEC deployment is not a realistic expectation... The beauty of DNSSEC being, of course, that any answer that verifies can be trusted - so its of no interest who provided that answer. -- http://www.apache-ssl.org/ben.html http://www.links.org/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
The 2008 IEEE Key Management Summit is Currently Seeking Panelists
The 2008 IEEE Key Management Summit (KMS) is currently seeking six panelists to act as the voice of customers who have purchased or plan to purchase a cryptographic key management solution. The panels will be moderated by leading analysts Jon Oltsik of the Enterprise Strategy Group, and Ramon Krikken of the Burton Group. If you are interested in participating or know of someone who might be interested, please send an e-mail to [EMAIL PROTECTED] Examples of industries we would like to hear from: - Financial -- banks, credit card processing, credit unions, mutual fund managers, etc - Health Care -- key management for HIPAA compliance, etc - Government -- handling sensitive but unclassified information See more details at http://www.keymanagementsummit.com/2008/ About KMS 2008: The IEEE Key Management Summit brings together the top companies that develop cryptographic key management for storage devices with the standards organizations that make interoperability possible and the customers that rely on key management to secure their encrypted data. With recent legislation, such as California's SB 1386 or Sarbanes-Oxley, companies now have to publicly disclose when they lose unencrypted personal data. To meet this new need for encryption, many companies have developed solutions that encrypt data on hard disks and tape cartridges. The problem is that these data storage vendors need a solution for managing the cryptographic keys that protect the encrypted data. This summit aims to provide clarity to the key management by showing how existing products and standards organizations address the problem of interoperability and security. KMS 2008 is co-located with the IEEE Mass Storage and Systems Technologies conference http://storageconference.org/2008/ (MSST) in Baltimore, Maryland on September 23-24, 2008. Thanks! Matt Ball, Chair, KMS 2008 Phone: 303-469-2469, Cell: 303-717-2717 http://www.linkedin.com/in/matthewvball - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Securing the Network against Web-based Proxies
Ah, where the web is going. 8e6 Technologies sells a hardware box that it claims does signature analysis to detect HTTP proxies and blocks them. It can also block HTTPS proxies that do not have a valid certificate (whatever that means), as well as do such things as block IM, force Google and Yahoo searches to be done in Safe mode, and so on. They're marketing this to the education community (with the typical horror stories of the problems your school district can run into if students use proxies to get around your rules). What I find most interesting, though, is that the company, based in California, has an overseas presence in exactly two other countries: Taiwan and China. One doesn't need much imagination to see what market they are going after there -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
