Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security FullDisclosure
[Top] [All Lists]

Re: [Full-disclosure] SmartCards programming...

Subject: Re: [Full-disclosure] SmartCards programming...
Date: Wed, 23 Nov 2005 14:57:04 -0500
On Wed, 23 Nov 2005 09:41:46 +0100, khaalel said:

(Others have provided pointers to info on smart cards, so I'm going to make
some comments about the difference between "using a smart card" and "actual
security"...)

The goal is to write the programs and all the associated stuff... in order
to create a  DRM-like system: when an user enter his card, a software check
his key (or certificate or...) and if  the authentication succeed, the
wanted file (document, video, audio...) is open by the software...

The tough part here is figuring out how to have the software open the file,
but ensure that the contents are in fact inaccessible without the smart card.
In particular, securely handling the data after opening to ensure that the
data can't be saved in an unencrypted form is fiendishly difficult, as every
single DRM scheme to date has demonstrated....

have to learn? Which type of smart cards I have to buy? Which algorithms I
can use (DES, RSA, Elliptic Curves, AES...)??

With the exception of single-DES, which is known to be weak for today's
hardware (triple-DES still has quite some lifetime, at least for
not-too-sensitive data - it's fine for securing a track on a music CD, but
maybe not for a nuclear missle launch code), the algorithm used really doesn't
matter.  There's only 3 basic things you actually need to get right:

1) Choosing symmetric or public-key.

2) Choosing a key/data length large enough to make a brute force attack not
worth it (again, this depends on the value of the data being secured).

3) Key management - more actual implementations manage to get this wrong than
do the actual crypto wrong.  You can do the crypto in a totally secure manner, 
but
it's still total security manure suitable for fertilizing the flower garden if
a keystroke logger can easily sniff the passphrase....

All the rest is details and engineering choices (speed versus power consumption,
and so on)....

Attachment: pgpZNBkhWHQ2b.pgp
Description: PGP signature

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
<Prev in Thread] Current Thread [Next in Thread>