RE: link fest on fingerprint biometrics
On 08 September 2006 00:38, Travis H. wrote: At home I have an excellent page on making fake fingerprints, but I cannot find it right now. It used gelatin (like jello) and was successful at fooling a sensor. http://search.theregister.co.uk/?q=gummi should be a start. cheers, DaveK -- Can't think of a witty .sigline today - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: link fest on fingerprint biometrics
* Travis H. schrieb am 2006-09-08 um 01:37 Uhr: If anyone can give me any fingerprint-related links, particularly about spoofing/breaking them, I would be grateful. http://www.ccc.de/biometrie/fingerabdruck_kopieren?language=en -- Jens Kubieziel http://www.kubieziel.de Man muss Rekursion verstanden haben, um Rekursion zu verstehen. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Exponent 3 damage spreads...
This is a multi-part message in MIME formatthought this might interest people here. -- 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 ---BeginMessage--- I've just noticed that BIND is vulnerable to: http://www.openssl.org/news/secadv_20060905.txt Executive summary: RRSIGs can be forged if your RSA key has exponent 3, which is BIND's default. Note that the issue is in the resolver, not the server. Fix: Upgrade OpenSSL. Issue: Since I've been told often that most of the world won't upgrade resolvers, presumably most of the world will be vulnerable to this problem for a long time. Solution: Don't use exponent 3 anymore. This can, of course, be done server-side, where the responsible citizens live, allegedly. Side benefit: You all get to test emergency key roll! Start your motors, gentlemen! Cheers, Ben. -- 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] ---End Message---
Re: signing all outbound email
At 7:02 AM +1000 9/8/06, James A. Donald wrote: I do not seem to be able to use DKIM to for spam filtering. Correct. It is for white-listing. It tells the recipient (MTA or MUA) that the message received was sent from the domain name it says it was, and that parts of the message were not altered. I would like to whitelist all validly signed DKIM from well known domains. Good; that's what the protocol is designed to do. One way of doing this would be for the MTA to insist on a valid signature when talking to certain well known MTAs, and then my MUA could whitelist mail sent from those well known MTAs Yes, if you are willing to throw out messages whose signatures are broken during transit. (This is the same risk that others face with insisting on valid S/MIME or OpenPGP signatures be on every message from particular parties.) In short, I am not able to get any advantage out of using this protocol, which means that there is no advantage in sending me signed mail. And there is no disadvantage either. There is advantages for sending signed mail to users who have a different threat model than you have, and there are certainly administrative advantages to signing all outgoing mail, not looking to see oh, if it is James, don't sign it because he won't like it. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: RSA SecurID SID800 Token vulnerable by design
Hadmut Danisch wrote: Hi, I recently tested an RSA SecurID SID800 Token http://www.rsasecurity.com/products/securid/datasheets/SID800_DS_0205.pdf The token is bundled with some windows software designed to make user's life easier. Interestingly, this software provides a function which directly copies the current token code into the cut-and-paste buffer, when the token is plugged in into USB. This is weak by design. The security of these tokens is based on what RSA calls two-factor user authentication: It takes both a secret (PIN) and the time-dependend Token-Code to authenticate. The security of the Token-Code depends on the assumption that the token is resistant against malware or intruders on the computer used for communication (web browser, VPN client,...). Hi Hadmut, Another problem from what I see with Malware that steals data is the formgrabbing and on event logging of data. Malware can detect if SecureID is being used based on targeted events, example: Say HSBC (Hypothetical example, not targeting HSBC) has two-factor logins in place, the problem with this is that it is vulnerable to session riding and trojan-in-the-middle attacks anyway, because the minute the user logs in, the malware could launder money out (unless transaction auth is in place, which in most cases it's not), or they could pharm the user with a fake website that resolves as HSBC but they go in within the time frame of that token being valid and have access. Either way, however you cut it, SecureID/Two-Factor User auth is not protected against malware, period. However, if the Token Code can be read over the USB bus, this assumption does not hold. A single attack on the PC where the token is plugged in would compromise both the PIN (e.g. with a keylogger) and the token itself (e.g. writing a daemon which continuously polls the token and forwards the token in real time to a remote attacker. Ironically this could make an attack even easier: If some malware simultaneously monitors the token and the keyboard, it is much easier to detect that the keystrokes are actually related to some login procedure: Whenever the 6-digit token code appears in the keyboard or cut-and-paste input stream, you can be pretty sure that in a sliding window of about the last 100-200 keystrokes both the PIN and the address of the server to login is contained. Makes it really easy to automatically detect secrets in the input stream. Thus, two different authentication methods are together weaker than each single one. regards Hadmut - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] -- Best Regards, Lance James Secure Science Corp. http://www.securescience.net - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: RSA SecurID SID800 Token vulnerable by design
Hi Lance, On Fri, Sep 08, 2006 at 10:26:45AM -0700, Lance James wrote: Another problem from what I see with Malware that steals data is the formgrabbing and on event logging of data. Malware can detect if SecureID is being used based on targeted events, example: Say HSBC (Hypothetical example, not targeting HSBC) has two-factor logins in place, the problem with this is that it is vulnerable to session riding and trojan-in-the-middle attacks anyway, because the minute the user logs in, the malware could launder money out (unless transaction auth is in place, which in most cases it's not), or they could pharm the user with a fake website that resolves as HSBC but they go in within the time frame of that token being valid and have access. Either way, however you cut it, SecureID/Two-Factor User auth is not protected against malware, period. Partly agreed. These kinds of attacks I usually teach in my workshops. However, in all of these cases the attacker has to be online in the moment you are logging in and you experience any failure, e.g. can't login or something like that. But with the SID800 malware could silently sit in the background and pass token codes to the attacker even if you do not login at this moment. E.g. it could wait until you have logged in (or out) and grap the next token code. Furthermore, the attack you described presumes that the attacker knows where you want to login. But when you could use the current token code as an indicator for searching login data in the input stream, then you can find new places to login, e.g. your company VPN access point. While the attack you describe is more important for banking, the USB attack is more against company logins. regards Hadmut - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: RSA SecurID SID800 Token vulnerable by design
Hadmut Danisch wrote: Hi Lance, On Fri, Sep 08, 2006 at 10:26:45AM -0700, Lance James wrote: Another problem from what I see with Malware that steals data is the formgrabbing and on event logging of data. Malware can detect if SecureID is being used based on targeted events, example: Say HSBC (Hypothetical example, not targeting HSBC) has two-factor logins in place, the problem with this is that it is vulnerable to session riding and trojan-in-the-middle attacks anyway, because the minute the user logs in, the malware could launder money out (unless transaction auth is in place, which in most cases it's not), or they could pharm the user with a fake website that resolves as HSBC but they go in within the time frame of that token being valid and have access. Either way, however you cut it, SecureID/Two-Factor User auth is not protected against malware, period. Partly agreed. These kinds of attacks I usually teach in my workshops. However, in all of these cases the attacker has to be online in the moment you are logging in and you experience any failure, e.g. can't login or something like that. But with the SID800 malware could silently sit in the background and pass token codes to the attacker even if you do not login at this moment. E.g. it could wait until you have logged in (or out) and grap the next token code. Furthermore, the attack you described presumes that the attacker knows where you want to login. But when you could use the current token code as an indicator for searching login data in the input stream, then you can find new places to login, e.g. your company VPN access point. While the attack you describe is more important for banking, the USB attack is more against company logins. Agreed, and since my research is focused on online banking I can see yours and my point, either way, SecurID should not be the only concept for dependence. regards Hadmut -- Best Regards, Lance James Secure Science Corp. http://www.securescience.net - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Locating private keys in RAM?
The link to the paper is broken but this one works: http://www.cs.jhu.edu/~astubble/600.412/s-c-papers/keys2.pdf#search=%22k eyhide2.pdf%22 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Sent: Wednesday, September 06, 2006 1:21 AM To: Douglas F. Calvert Cc: cryptography@metzdowd.com Subject: Re: Locating private keys in RAM? Am Dienstag 05 September 2006 03:14 schrieb Douglas F. Calvert: Hello, I remember seeing a paper about identifying private keys in RAM. I thought it was by Rivest but I can not locate it for the life of me. Does anyone remember reading something like this? The basic operation was to identify areas in RAM that had certain characteristics such as random bits and identifiable key headers... Any help would be greatly appreciated... This one? http://www.ncipher.com/products/files/papers/anguilla/keyhide2.pdf and code for it: http://www.thc.segfault.net/releases/keyfinder.c -- Tom [EMAIL PROTECTED] fingerprint = F055 43E5 1F3C 4F4F 9182 CD59 DBC6 111A 8516 8DBF - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: link fest on fingerprint biometrics
On Thu, 7 Sep 2006, Travis H. wrote: At home I have an excellent page on making fake fingerprints, but I cannot find it right now. It used gelatin (like jello) and was successful at fooling a sensor. I did find this, which reports success with gummi bears: http://msn.pcworld.com/article/id,116573-page,5/article.html [...] If anyone can give me any fingerprint-related links, particularly about spoofing/breaking them, I would be grateful. I have never understood the hype around creating fake fingers; looking at the technology behind the sensors makes it rather obvious that it is possible -- in fact, there is a discussion within ISO JTC1/SC37 (the ISO group standardizing biometrics) about evaluating the quality of images produced by fingerprint scanners by using a synthetic finger created following a standardized procedure [1] in order to get reproduceable results. But I agree that it is sounds cute that you can create fake fingers out of gummy bears... One IMHO more interesting question is the FAR (False Accept Rate = the probability that an impostor is accepted) of the algorithm. (And I note that some of the gummy finger articles I have read have been done with algorithms with low enough FAR that the author could have got a match by inviting ~5 friends to try to match against his finger... This is probably a more realistic attack, but it also mean that the fake finger may work even if it look rather different from the real fingerprint.) It can be a bit hard to get relevant numbers from vendors, but NIST has recently done extensive testing using real world data. The result [2] gives a detailed picture about the performance of fingerprint systems (the Minex test was however done using standardized templates; the result of each vendor is in general much better when using proprietary templates. See e.g. [3] for an older test using proprietary templates). The NIST image group web site [4] has more nice stuff, including a rather good implementation of a fingerprint matcher. I can also highly recommend the book [5] in case you are really interested in algorithms for fingerprint recognition... /Krister [1] Document 37N0847 and 37N1661 in case you have access to the SC37 document archive. [2] http://fingerprint.nist.gov/minex04/index.html [3] http://fpvte.nist.gov/index.html [4] http://fingerprint.nist.gov/ [5] Handbook of Fingerprint Recognition Davide Maltoni, Dario Maio, Anil K. Jain, Salil Prabhakar - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: RSA SecurID SID800 Token vulnerable by design
One can have a lot of fun with key-wielding tokens, especially on Windows. See: J. Marchesini, S.W. Smith, M. Zhao. Keyjacking: the Surprising Insecurity of Client-side SSL. Computers and Security. 4 (2): 109-123. March 2005. http://www.cs.dartmouth.edu/~sws/pubs/msz05.pdf --Sean Sean W. Smith [EMAIL PROTECTED] www.cs.dartmouth.edu/~sws/ Department of Computer Science, Dartmouth College, Hanover NH USA - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
