datamining the NSA
The recent story on datamining the NSA is getting a lot of airplay here in Austria. I gather it was slashdotted, and can be found on "datamining the NSA." We just listened to a half hour long interview in prime time (7pm) on national radio on the subject. In german. (Accidentally, I happen to be jacked in at the offices of the organisation that did the datamining, or some such.) It's also been in major newspapers, so I'm told. The background of the story appears to have a lot of relevence to the wider identity debate. In brief, it looks like there was a several-year tussle between the NSA (voice recognition), the FBI (fingerprints) and the British (iris scanning) over what the standard for biometrics should be. No mention yet as to whether any of this data should be encrypted and thus protected from aggressive threats, such as those mooted in the passport-rfid debate. There are also eyebrow-raising comments on how important components of the biometric technology was developed by American firms as standard approaches for american systems, and is now owned by the French government... iang -- News and views on what matters in finance+crypto: http://financialcryptography.com/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: No Encryption for E-Passports
See the following comments submitted to the Department of State - 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] === Comments on the Department of State Public Notice 4993 (RIN 1400 AB93) about Electronic Passport March 7, 2005 by Thierry Moreau CONNOTECH Experts-conseil inc. 9130 Place de Montgolfier Montr‚al, Qc, Canada H2M 2A1 Tel.: +1-514-385-5691 Fax: +1-514-385-5900 E-mail: [EMAIL PROTECTED] Internet: http://www.connotech.com Introduction We appreciate the opportunity to submit comments on the electronic passport (e-passport) global project and proposed regulation changes ([1]). Some of these comments have a broader scope than the regulation change (this seems to be invited by the Department of State by the public notice discussion of e-passport encryption debate, i.e. [1] page 8306, center column, 2nd to 4th paragraphs). Our comments are centered on the information security aspects of the e- passport global project, notably the ICAO Public Key Infrastructure (PKI) framework, i.e. [2]. The uniqueness of security requirements for the global interoperability of e-passports has been recognized early in the ICAO development process that brought the document [2] to its current version. As a result, most of the traditional PKI concepts has been omitted or simplified. We believe there are merits in the scheme found in the document [2] for the e- passport security, including the selection of un-encrypted e- passport electronic chip data. The driving design criteria has been operational hindsight rather than conservatism. We are concerned that this hindsight is not always reflected in the [1] public notice. Our comments below are itemized, and they do not have equal importance, significance, or relevance to the specific regulatory change. Unencrypted e-passports is a valid direction We generally concur with the ICAO selection of unencrypted e-passports. Encryption would mean a global key management scheme to determine the circumstances in which an e-passport would be unlocked by a reader. Such a key management scheme would imply granting reading rights to some organizations and denying such rights to others. Those opposing the unencrypted e-passports would certainly be even more suspicious of any workable key management scheme for encrypted e-passports. We have yet to see any suggestion as a key management scheme that might appear acceptable to a security expert who claimed that unencrypted e-passport are putting US citizens at risk. This explanation seems reflected in the Department of State statement that "in order to be globally interoperable, encryption would require a higher level of technology and more complicated technical coordination with other nations." ([1] page 8306, center column, 2nd paragraph) although we would have liked the Department of State to speak for itself (e.g. "Such technical coordination includes notably the cryptographic key management for electronic chip decryption keys."). Doubtful representation of e-passport technology, reader requirements and skimming threat According to the document [2], "Everyone who has the appropriate equipment is able to read the chip contents of the MRTD, but only the parties that are provided with the appropriate public key certificates and certificate revocation lists will be able to verify the authenticity and integrity of the chip contents." (Document section 2.4.4) So we find misleading the [1] public notice that eavesdropping requires a reader "furnished with the proper public key" ([1] page 8306, center column, 4th paragraph). In fact, reading of electronic chips by international transportation operators (e.g. airlines) is encouraged by the ICAO. The e-passport proponents should not minimize the significance of unauthorized e-passport reading threats. Anti-skimming features are important to US travelers wishing to protect their anonymity and privacy. The Department of State should provide reliable information about their effectiveness and their prudent use, since the momentary disabling of anti-skimming mechanisms (e.g. the removal of a metallic shield surrounding the electronic chip antenna) materializes the e-passport bearer authorization to read the e-passport. Doubtful representation of e-passport technology, global skimming countermeasures We are pu
Re: comments wanted on gbde
Re, GDBE-- Some initial thoughts: I wouldn't be surprised if platters couldn't be analyzed for usage levels / magnetic degradation (Peter?). Even without a clean room, ATA is pretty rich -- anyone remember the guy who graphically plotted the spiral damage caused by a falled drive head w/ nothing but a massively hacked ATA driver? There's also likely to be useful information from drive sectors duplicated by the drive firmware (there's extra space in every drive; when particular sectors are judged "buggy" content from them is migrated onto the spare space). I saw nothing establishing the integrity of sectors during *decryption* in 7.5. Random / polluted sectors will decrypt, though into unpredictable noise (which tends to do bad things to file system code). Previous versions of sectors will also decrypt successfully -- the cleaning lady can take lessons from Mallory, as it were. It's useful to immediately grant though that their threat model is much more aligned towards drives that will never be hot again. One wonders if there is a delivery service for Key-key's. --Dan - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
comments wanted on gbde
Steve Bellovin writes: >A "discussion" -- I'll be polite and call it that -- has erupted on >some mailing lists about gbde -- geometry-based disk encryption. With >the author's consent, I'm soliciting opinions from this group about it: >http://phk.freebsd.dk/pubs/bsdcon-03.gbde.paper.pdf I took a look at that paper. (I seem to recall looking briefly at actual GBDE code two or three years ago, but I have since forgotten everything I once knew about GBDE, so I was forced to read the paper and start from scratch.) Here are some thoughts. Warning: they are based solely on reading the above paper. I have not put a great deal of thought into this, nor have I examined any source code, so take everything with many grains of NaCl. My sense: GBDE isn't built the way I would have chosen to, and there are many aspects that I consider inelegant, but it doesn't look obviously broken. If you use it appropriately, it looks fairly reasonable, as far as I can tell. I would be willing to use it for my own personal secrets. I believe it is possible to use it in a way such that it will provide adequate security. However, I also believe it is possible -- and, perhaps, all too easy -- to use GBDE in a way that will not provide adequate security. My biggest fear is that safe usage is just hard enough that many users will end up being insecure. GBDE uses a passphrase to encrypt the disk. If you can guess the passphrase, you can decrypt the disk. Now in theory, all we have to do is tell users to pick a passphrase with at least 80 bits of entropy. However, in practice, this is a pipe dream. As we know, users often pick passphrases with very little entropy. Practices vary widely, but for many users, an estimate in the range of 10-40 bits is probably reasonable. Consequently, dictionary attacks are a very serious threat. GBDE does not take any steps to defend against dictionary attacks. In GBDE, a passphrase with b bits of entropy can be broken with 2^b AES trial decryptions. This means that people who are using passphrases with only 10-40 bits of entropy may be screwed -- their data will not be secure against any serious attack. 40-bit security is a very weak level of protection. So, this seems like it could be a real concern, depending on how GBDE is used and how much security you need. If you can train users to use strong passphrases, GBDE should be fine, I would think. For instance, human rights workers might be willing to deal with the usability costs of very long passphrases. However, many users may not have enough discipline to use very strong passphrases, and those users might be at risk. The GBDE paper has a rather peculiar comment about dictionary attacks. It mentions the possibility of using password stretching/strengthening techniques (e.g., PKCS#5, iteration to slow down dictionary attacks, etc.), but rejects them on the basis that they are not able to ensure perfect security in all cases. That strikes me as a rather weird stance. They in no case make things worse, and in many cases may provide a measurable improvement. I agree that such mechanisms are imperfect, and there are severe limits on how much they can help, but they still seem better than doing nothing about dictionary attacks. This strikes me as an unfortunate aspect of GBDE. A second possible critique of GBDE is that the design seems a little strange in several places. There is no clear explanation of the threat model GBDE is intended to protect against, or the security goals it is intended to achieve. The design is unnecessarily complex and baroque. I should elaborate. The threat model: What can we assume about the attacker's capabilities? What kinds of attacks are we trying to defend against? One scenario is where a hard disk is stolen, the attacker gains access, and wants to read the data. But what about other threats? The paper mentions the "cleaning lady" threat, where an attacker gains physical access to the hard disk at multiple times, without being detected. Do we want to defend against such attacks? If we do, we need chosen-ciphertext security, because otherwise the attacker might be able to tamper with data on the disk and thereby learn information about the plaintext. The GBDE paper does not clearly say whether GBDE is intended to design against this threat model, and I have serious doubts about whether it would be secure against such a threat; the modes are certainly not chosen-ciphertext secure. So can we assume we do not need to defend against such threats, and that if the attacker ever gains access to the hard disk, then we will learn of this fact and never use the hard disk again? As another example, can we assume that the communication between the computer and the hard disk is physically secure, or might GBDE be used with NFS (for example)? Also, the security goals are never precisely stated. Is the only goal to protect the confidentiality of stored data? Do we also want to prevent "traffic analys
Re: MD5 collision in X509 certificates
Anne & Lynn Wheeler <[EMAIL PROTECTED]> writes:
>the purpose of a certificate is analogous to the old letters of credit in the
>sailing ship days it supposedly establishes the bonifides of the
>individual in an offline, non-connected world where the relying party has no
>other recourse regarding trust/integrity of the individual that they are
>dealing with.
I ran into an interesting example of the conflict between PKI's almost
completely offline design vs.the almost completely online world recently.
Someone showed me a full-page diagram of their PKI/certificate management
process containing several dozen boxes, a maze of connecting arrows, labels,
references to pages and pages of further explanation, etc etc etc. After
reverse-engineering the process displayed in the diagram over a period of
about quarter of an hour, I simplified the whole thing by drawing a single
line from the top left ("I have someone's public key") to the bottom right
("Ask an online service who it belongs to and whether it's OK to use"),
completely bypassing the morass of PKI in the middle. (This is a bit like the
financial industry use of PKI that Lynn mentioned a while back in which you
throw away everything but the public key and check that directly, because all
the PKI does is get in the way).
At that point the conversation went something like this:
"Why not do it that way then, since that's the end effect anyway?".
"We can't do that. $LARGE_ORGANISATION have spent millions of dollars
setting up their PKI, and they won't allow something that sidesteps it".
"So the only reason the PKI is there is because not having it there would be
an admission of its uselessness?"
"Uhh, yeah".
This leads to the following PKI business model:
1. Spend millions of dollars setting up a PKI.
2. Everyone is forced to use it because not to do so would be a waste of the
setup costs.
3. Profit!
Peter.
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: MD5 collision in X509 certificates
On 3/5/05, [EMAIL PROTECTED] (Anne & Lynn Wheeler) wrote: >The implication is that if i can substitute a public key in some >certificate that attests to represent some other party then it may >be some form of identity theft (fraudulent messages can be created that >otherwise appear to have originated from you ... and validate with the >substituted public key). The other might be elevation of privileges >adding characteristics to a certificate that were otherwise not provided. The real concern, and there is no evidence that it is easy, is that if a certificate is signed using a MD5 hash, and another certificate, with a different (RSA) public key, can be substituted, maintaining the signature, then it will be probable that the new public key will be the product of many primes, and (relatively) easy to factor. If this were possible, it would lead to identity theft. While this scenario is not, as far as I know, easy, it seems to me that it is time to abandon MD5 in signatures. The issues with SHA1 are worrisome, but not yet, IMHO, fatal. However, it would be prudent to plan on moving beyond SHA1 in the near future. All IMHO. 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: two-factor authentication problems
You're quite correct Matt, Which is why IMHO you can only really get true "non-repudiation" through use of PKI. And more specifically: - where the key pair was generated by the end-user, and - where the server has stored a copy of the transaction - digitally signed by the end user - which it can reproduce in court. In this case, a corrupt operator could not have faked the transaction even if they had wanted to. RSA SecureID and OATH technology have some great virtues: - they cost nothing to integrate at the client end - there is no client "footprint" so there's nothing to go wrong - they are relatively easy to understand and use - they're unquestionably better than reliance on user IDs and passwords. What they won't do is: - provide non-repudiation - defend against man-in-the-middle attacks, or - provide a robust defence against phishing scams And for these reasons I suspect their days are numbered. All the best, Gabriel Haythornthwaite [EMAIL PROTECTED] Phone: +61 412 544 632 Fax: +61 2 9798 3935 www.castelain.com.au > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Matt Crawford > Sent: Monday, 7 March 2005 1:38 PM > To: Ed Gerck > Cc: cryptography@metzdowd.com > Subject: Re: two-factor authentication problems > > > > On Mar 5, 2005, at 11:32, Ed Gerck wrote: > > > The worse part, however, is that the server side can always > fake your > > authentication using a third-party because the server side > can always > > calculate ahead and generate "your next number" for that > third-party > > to enter -- the same number that you would get from your > token. So, if > > someone breaks into your file using "your" number -- who is > > responsible? The server side can always deny foul play. > > Huh? The server can always say "response was good" when it wasn't > good. Unless someone reclaims the server from the corrupt > operator and > analyzes it, the results are the same. > > > - > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to > [EMAIL PROTECTED] > - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
