Levels of security according to the easiness to steel biometric data
Hi, Probably you have heard about this: CCC publishes fingerprints of German Home Secretary Date: 31 March 2008 Source: Heise.de In a protest against the use of biometric data, the Chaos Computer Club (CCC) has taken a step that will raise a few eyebrows in the current issue of its club magazine Die Datenschleuder, the hackers have published the fingerprint of German Home Secretary, ... Link: http://www.liveleak.com/view?i=b29_1206968252 QUESTION: Does anybody knows about the existence of a security research in area of grading the easiness to steel biometric data. For example, I guess that stealing information of someone's face is easier than stealing information about someone's fingerprints, but stealing information about someone's retina would be much harder. Such a scale can be useful in the design of secure protocols and secured information systems. Danilo Gligoroski! - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: presentations about encrypted storage
While the presentations are useful in identifying various encrypted storage technologies, Travis, there is little mention of key-management in them. If you are interested in enhancing your presentations and your book to mention a specific implementation, there is a fair amount of material available on a new protocol (in the process of becoming an OASIS standard) and an open-source solution that has implemented it. You will find more details on both at: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ekmi http://www.strongkey.org. Finally, a first Key Management Summit is scheduled to be held in Baltimore, MD this fall, that should be of interest to people in this forum: http://www.keymanagementsummit.com/2008/ Arshad Noor StrongAuth, Inc. [EMAIL PROTECTED] wrote: I've got two presentations I've given on encrypted storage technologies here: http://www.subspacefield.org/security/ There's also a book I'm writing, if anyone is interested. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: how to read information from RFID equipped credit cards
On Tue, Apr 01, 2008 at 12:47:45AM +1300, Peter Gutmann wrote: Actually there are already companies doing something like this, but they've run into a problem that no-one has ever considered so far: The GTCYM needs a (relatively) high-bandwidth connection to a remote server, and there's no easy way to do this. You can get a fairly high-bandwidth channel with 2D barcodes. It's uni-directional, but that's enough for many useful scenarios. The data gets shown on the PC monitor and is captured by a ubiquitous camera-phone or a dedicated locked-down device. This approach avoids the problems you mentioned about USB/Firewire/Ethernet lockdown. Disclosure: I work for a company, Cronto, which makes a product based around this technology -- http://www.cronto.com/ Steven. -- w: http://www.cl.cam.ac.uk/users/sjm217/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: how to read information from RFID equipped credit cards
Steven J. Murdoch [EMAIL PROTECTED] writes: You can get a fairly high-bandwidth channel with 2D barcodes. It's uni- directional, but that's enough for many useful scenarios. The data gets shown on the PC monitor and is captured by a ubiquitous camera-phone or a dedicated locked-down device. This approach avoids the problems you mentioned about USB/Firewire/Ethernet lockdown. That's what one company ended up using, not specifically 2D barcodes but a visual channel via the PC monitor (actually nothing like 2D barcodes in this particular case :-). The problem is, as you point out, that the channel is unidirectional and not very high-bandwidth. This makes the crypto very hard because you have to roll your own protocols and mechanisms and everything ends up custom and nonstandard. Here's an interesting crypto design problem, how do you do something like S/MIME or PGP (to submit or receive an authenticated request/purchase order/ whatever) with a relatively low-bandwidth channel in one direction and almost no channel (perhaps humans typing in a 4-digit number) in the other, and without requiring huge amounts of oddball custom crypto mechanisms. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: how to read information from RFID equipped credit cards
On Tue, Apr 01, 2008 at 12:47:45AM +1300, Peter Gutmann wrote: Actually there are already companies doing something like this Which ones do you think are doing a decent job of this? but they've run into a problem that no-one has ever considered so far: The GTCYM needs a (relatively) high-bandwidth connection to a remote server, and there's no easy way to do this. (Hint: You can't use anything involving USB because many corporates lock down USB ports to prevent data leaking onto other corporates' networks, or conversely to prevent other corporates' data leaking onto their networks. Same for Ethernet, Firewire, ...). Lock USB down completely, or block most devices and allow approved ones? There is a non-empty set folks doing the latter, which opens the possibility of this type of device being permitted, while others are restricted. Since *all* it needs is the ability to call home to its server, and register to send/receive messages, it will not look like mass-storage, and should not look like a network interface. Data leakage should not be a concern if the device is built/marketted correctly. -- Viktor. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [p2p-hackers] convergent encryption reconsidered -- salting and key-strengthening
On Mar 31, 2008, at 4:47 AM, Ivan Krstić wrote: Tahoe doesn't run this service either. I can't use it to make guesses at any of the values you mentioned. I can use it to make guesses at whole documents incorporating such values, which is in most cases a highly non-trivial distinction. The way that I would phrase this is that convergent encryption exposes whatever data is put into it, in whatever batch-size is put into it, to brute-force/dictionary attacks. If the data that you put in is unguessable, then you needn't worry about these attacks. (Likewise, as Ben Laurie reminds us, using strong passwords is a sufficient defense against these attacks on passwords.) You correctly emphasize that typical convergent encryption services (which operate on files, or, in the case of GNUnet, on 32 KiB blocks), and typical uses of those services (which typically store files as produced by apps written for traditional filesystems), batch together data in such a way that the aggregate is more likely to be unguessable than if each field were stored separately. I don't disagree with this observation. I am often reminded of Niels Ferguson's and Bruce Schneier's dictum, in the excellent _Practical_Cryptography_, that security needs to be a *local* property. They argue that one should be able to tell whether a component is secure by inspecting that component itself, rather than by reasoning about interactions between that component and other components. Concretely, convergent encryption with a per-user added secret, as currently implemented in Tahoe, can be shown to guarantee confidentiality of the data, regardless of what the data is. Traditional convergent encryption can be shown to offer confidentiality only with the proviso that the data put into it conform to certain criteria -- criteria that cannot be verified by a computer nor by a user who is not a skilled security expert. You may argue that the chance that a user would put non-comformant data into it is small. I don't necessarily disagree, although before I became willing to bet on it I would require more quantitative investigation. However, arguing that component A is secure as long as component B behaves a certain way, and that component B is very likely to behave that way, is a different sort of argument than arguing that component A is secure regardless of the behavior of component B. For one thing, the behavior of component B may change in the future. Concretely, people may write apps that store data in Tahoe in a way that previous apps didn't. Those people will almost certainly be completely unaware of the nature of convergent encryption and brute- force/dictionary attacks. Now obviously making the security properties of a system modular in this way might impose a performance cost. In the case of Tahoe, that cost is the loss of universal convergence. Allmydata.com analyzed the space savings due to convergence among our current customers and found that it was around 1% savings. We (allmydata.com) intend to monitor the potential savings of universal convergence in an on-going way, and if it turns out that there are substantial benefits to be gained then I will revisit this issue and perhaps I will be forced to rely on an argument of the other form -- that users are unlikely to use it in an unsafe way. Thank you again for your thoughtful comments on this issue. Regards, Zooko O'Whielacronx - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Want to drive a Jaguar?
Peter Gutmann wrote: http://eprint.iacr.org/2008/058 Physical Cryptanalysis of KeeLoq Code Hopping Applications Addition (http://www.heise-online.co.uk/security/news/print/110446): Scientists at the Ruhr-Universität Bochum[1] have defeated the Keeloq[2] immobiliser and door opener used in many cars. Attackers need only intercept two transmissions between the transmitter and receiver in order to clone the digital key and gain access to the car. Microchip Technology's RFID-based KeeLoq process, is used in automobiles manufactured by Chrysler, Daewoo, Fiat, General Motors, Honda, Toyota (Lexus), Volvo, Volkswagen and Jaguar. KeeLoq is also used in building access systems and garage door openers. Signal interception is possible at a range of 100 metres, according to Professor Christof Paar of the School of Electronics and Information Technology. In addition to gaining unauthorised access, the systems can be manipulated, denying the rightful owners access. Both the KeeLoq transmitter and receiver encrypt their signals. A proprietary, non-linear encryption algorithm is used which encrypts controller commands with a unique code before transmission to the vehicle. A 32 bit initialisation vector together with a 32 bit hopping code is used as a key. An ID unique to each electronic key is added to the calculation. But there is also a manufacturer's master key for all of the products in a series. This is precisely what Professor Paar's Bochum group was able to retrieve using a procedure known as side channel analysis. To obtain the master key the researchers used differential power analysis (DPA) and differential electromagnetic analysis (DEMA) at both the transmitter and receiver during the transmission. Once the master key is known, only two transmissions are needed in order to obtain the crypto key of a particular KeeLoq remote control. The vulnerability was tested on commercial systems, according the Bochum scientists. In early February the researchers presented a detailed description[3] of the attack that required them to intercept a number of activation procedures in order to obtain the manufacturer's key. At the CRYPTO 2007 cryptography conference, an international group of researchers presented a method by which the individual keys could be cracked[4] using distributed computing. Cheers, Stefan. [1] http://www.crypto.rub.de/en_news.html [2] http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGEnodeId=2074 [3] http://eprint.iacr.org/2008/058 [4] http://www.heise-online.co.uk/security/Computer-farm-cracks-car-key-code--/news/94874 - Identity Management Symposium 22.-23.04.2008 KA/Ettlingen http://www.identity-management-symposium.de/ - Stefan Kelm Security Consultant Secorvo Security Consulting GmbH Ettlinger Strasse 12-14, D-76137 Karlsruhe Tel. +49 721 255171-304, Fax +49 721 255171-100 [EMAIL PROTECTED], http://www.secorvo.de/ PGP: 87AE E858 CCBC C3A2 E633 D139 B0D9 212B Mannheim HRB 108319, Geschaeftsfuehrer: Dirk Fox - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
