Re: Is there any future for smartcards?
On Sun, Sep 11, 2005 at 06:49:58PM -0400, Scott Guthery wrote: > 1) GSM/3G handsets are networked card readers that are pretty > successful. They are I'd wager about as secure as an ATM or a POS, > particularly with respect to social attacks. The smartphones not secure at all, because anything you enter on the keypad and see on the display can be compromised, so the tamper-proof cryptographic goodness locked inside the SIM smartcard will cheerfully approve whatever the code running on the smartphone will tell it to approve, regardless of what is being displayed to the user. Virtually all new phones sold are smartphones, and for every platform there are documented vulnerabilities, exploits, and malware already in the wild. Increased use of mobile phones as means of payment are a strong motivation for malware writers. Most of smartphone users are security-naive teenagers. This indicates that we'll be getting all problems with desktop machines, and more, shortly. > 2) ISO is currently writing a standard for a secure home card reader. > The starting point is FINREAD. See JTC1/SC17/SG4/TF10. I own a secure home card reader (which happens on run on Windows, Linux and OS X, with open source drivers -- my model has a keyboard but no display, but other models from the same manufacturer do). Standars are good. I'm all for standars, as long as they describe what eventually will be a real world product. Unless financial institutions will be required by law to issue secure smartcards and smartcard readers, or suffer extreme losses through fraud they won't introduce these secure readers and smartcards. -- Eugen* Leitl http://leitl.org";>leitl __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
Re: Is there any future for smartcards?
I believe smartcards (and trusted computing platforms too, btw) aim to solve the following problem: "How to enforce your own security policy in a hostile environment, not under your own physical control?" Examples: - Smartcard: electronic purse: you cannot increase the amount on your e-purse (unless reloading at the bank). - Trusted computing: DRM: my content cannot be illegally copied on your machine. As soon as the environment is under your won physical control, software only solutions suffice. Regards, Jaap-Henk On Wed, 07 Sep 2005 18:08:25 -0400 Pat Farrell <[EMAIL PROTECTED]> writes: > Is there a real problem that they uniquely solve, sufficient > to drive the building of the needed infrastructure? > I don't see it, and I'd love to be made smarter. > > -- > Pat Farrell > http://www.pfarrell.com -- Jaap-Henk Hoepman | I've got sunshine in my pockets Dept. of Computer Science | Brought it back to spray the day Radboud University Nijmegen |Gry "Rocket" (w) www.cs.ru.nl/~jhh | (m) [EMAIL PROTECTED] (t) +31 24 36 52710/53132 | (f) +31 24 3653137 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: ECC patents?
Alexander Klimov wrote: On Sun, 11 Sep 2005, Ben Laurie wrote: Alexander Klimov wrote: ECC is known since 1985 but seems to be absent in popular free software packages, e.g., neither gnupg nor openssl has it (even if the relevant patches were created). It looks like the main reason is some patent uncertainty in this area. I don't, but it is not the case that OpenSSL does not include ECC. You are absolutely right the Sun patch was finally accepted, although there were some patent-related discussions, e.g., at http://lists.debian.org/debian-legal/2002/10/msg00100.html If debian wants OpenSSL to do something, then it needs to tell OpenSSL. We aren't telepaths. There is also work on ECC for gnupg http://www.g10code.de/tasklist.html#gcrypt-ecc and again there were patent-related discussions about the issue. ECC is also implemented in crypto++ and other libraries. But (potential) problem still persists: even if openssl implements ECC it does not save you from patent issues if they exist. It does if they are owned by Sun. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "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: ECC patents?
On Sun, 11 Sep 2005, Ben Laurie wrote: > Alexander Klimov wrote: > > ECC is known since 1985 but seems to be absent in popular free > > software packages, e.g., neither gnupg nor openssl has it (even if the > > relevant patches were created). It looks like the main reason is some > > patent uncertainty in this area. > > I don't, but it is not the case that OpenSSL does not include ECC. You are absolutely right the Sun patch was finally accepted, although there were some patent-related discussions, e.g., at http://lists.debian.org/debian-legal/2002/10/msg00100.html There is also work on ECC for gnupg http://www.g10code.de/tasklist.html#gcrypt-ecc and again there were patent-related discussions about the issue. ECC is also implemented in crypto++ and other libraries. But (potential) problem still persists: even if openssl implements ECC it does not save you from patent issues if they exist. -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Clearing sensitive in-memory data in perl
On Mon, 12 Sep 2005, Sidney Markowitz wrote: Does anyone know of an open source crypto package written in perl that is careful to try to clear sensitive data structures before they are released to the garbage collector? [...] Securely deleting secrets is hard enough in C, much less high level languages. I've often considered trying to write a C-based module for secret storage, but it's problematic (although the Taint stuff looks promising) and to my knowledge has never been done. -J - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
