Re: MUSCLE BOUNCE ["R. Argentini" ]

[David Sims]

Hi,

  I think the first recommendation that you should make to Schlumberger
is that they hire this guy when he graduates! He only ask lucid and
germaine questions

Dave

On Thu, 8 Feb 2001, David Corcoran wrote:

> 
> >To: [EMAIL PROTECTED]
> >From: "R. Argentini" <[EMAIL PROTECTED]>
> >Subject: E-Gate 5 Drivers?
> >Mime-Version: 1.0
> >Content-Type: text/plain; charset="us-ascii"; format=flowed
> >
> >Hello everybody. My name is Ranieri Argentini and i am a student a the
> >Delft University of Technology in the Netherlands.
> >In its effort to set up a common and comprehensive
> >authentication/authorisation framework the university has been handing out
> >student passes with smarcards and smardcard readers to students.
> >
> >The reader set consists of a 2-tel (www.2-tel.nl) E-Gate 5 smartcard reader
> >and MS Windows PC/SC drivers. This of course leaves the people running
> >something else than windows out in the cold, and there are quite a few
> >Linux/Unix users at a tech uni.
> >
> >Some other people and I have taken it upon us to try and see if we can get
> >it to work in Linux. The problem seems to be though (as you might have
> >guessed from the Subject line :) that there are no PC/SC Lite drivers
> >available for the reader in question. Since the university has already been
> >handing out a lot of them, i suppose there's little hope in getting them to
> >switch to a supported reader.
> >
> >Now for the questions :)
> >
> >(1)
> >Is it possible that the thing will work with some sort of "generic" driver?
> >We are talking about a serial reader that contains little electronics. The
> >most notable feature is a very small IC that bears the name "HC132". This
> >is most likely an oscillator. There are also quite a number of very very
> >tiny two and three terminal things i presume to be resistors and
> >transistors though they are definately not the ones we use in electronics
> >lab. Further there's one inductance and a couple of things that might very
> >well be power transistors near the 9V DC in. The whole thing is mounted on
> >a 1x1,5 inch PCB.
> >Does this sound familiar to anyone? If anyone is in doubt i will gladly
> >post a picture to the list :)
> >
> >(2)
> >Does anyone have some useful hints about what to say if i have to write to
> >the manufacturer to ask them to please ontribute a driver or some specs?
> >What has worked in the past? What hasn't?
> >
> >(3)
> >In case all else fails, do i have any hope to conjure up a driver any other
> >way? That is, reverse engineering the windows driver, or trying to capture
> >serial port traffic during authentication or something like that?
> >
> >Thank you for your attention,
> >
> >Ranieri.
> >
> 
> David CorcoranPurdue University
> 1008 Cherry Lane
> West Lafayette, IN 47906
> [EMAIL PROTECTED]
> 765 - 532 - 6006  http://www.linuxnet.com
> 
> 
> ***
> Linux Smart Card Developers - M.U.S.C.L.E.
> (Movement for the Use of Smart Cards in a Linux Environment)
> http://www.linuxnet.com/smartcard/index.html
> ***
> 

***
Linux Smart Card Developers - M.U.S.C.L.E.
(Movement for the Use of Smart Cards in a Linux Environment)
http://www.linuxnet.com/smartcard/index.html
***

Re: MUSCLE standards

[David Sims]

Hi,

  What about TCP/IP over ethernet?? That's an infrastructure just like 
smartcards are an infrastructure... It's the applications that a
ubiquitous card/reader system would enable that are 
important... and I daresay required befor smartcards become
ubiquitous

  Applications can be as diverse as the people of the world... The key
issue is: If the cards and readers were ubiquitous and interoperable,
a particular application could work anywhere that there was software
support for it infinite flexibility...

  Heck, what kind of world would it be if you had to have a particular
kind of computer for every website that you might want to browse?? A token
ring computer for websites on token ring, a Compaq computer for websites
hosted by a Compaq server??

Dave Sims

On Wed, 17 May 2000, Alex Pilosov wrote:

> On Thu, 18 May 2000, Matthias Bruestle wrote:
> 
> > If you really do all this, you will have one card with one operating
> > system.
> Ein volk, ein card, ein system. 
> 
> Sorry, I just couldn't resist ;)
> 
> -alex
> 
> ***
> Linux Smart Card Developers - M.U.S.C.L.E.
> (Movement for the Use of Smart Cards in a Linux Environment)
> http://www.linuxnet.com/smartcard/index.html
> ***
> 

***
Linux Smart Card Developers - M.U.S.C.L.E.
(Movement for the Use of Smart Cards in a Linux Environment)
http://www.linuxnet.com/smartcard/index.html
***

Re: MUSCLE standards

[David Sims]

Hi Dave,

  In the beginning of the Internet, there was a guy (whose name I can't
remember) who published a periodical (I wouldn't call it a magazine but
sort of) called 'ConneXions'... It featured articles (papers) by such
luminaries as Marshall Rose, Vint Cerf, etc. discussing layers and
protocols. It's theme was 'interoperability' and in fact it was the
pre-cursor of the 'Interop' trade show The guy that started ConneXions
also started the Interop... 

  I think that the same model could easily be applied to smartcards and
that this is a good forum for doing so... 

Dave Sims
**
On Wed, 17 May 2000, David Corcoran wrote:

> Hi, here is a bit that I wrote up to vent on my lack of standards in the
> smartcard industry.  Let me know if you agree or not.
> 
> One of the biggest obstacles in the smartcard industry today is the lack
> of standardization between different cards, readers, and even the platform
> in which they are used.  Back in the early days of the internet many
> different standards existed like token ring, Dec Net, and others making
> the existance of a single infrastructure in which anyone could plug into
> difficult.  Eventually the players began to see the light and one standard
> emerged as the godfather of all internet connectivity standards: ethernet
> and TCP/IP.  Now anyone can plug into the internet and connect with nearly
> everyone else in a simple and seamless manner.  It is no wonder why
> companies such as Cisco are doing as well as they are.  Do you think that
> these companies would be doing as well if many networking standards still
> existed today ?  The Internet would not be growing as quickly if not a
> single standard emerged from the struggle because users need a seamless
> way of connectivity.  The same must exist for smartcards.  Although
> magnetic stripe cards are of a much simpler nature, it is still possible
> for myself to travel to France and use an Automatic Teller Machine to gain
> access to money.  I can even use my VISA card in almost every terminal  
> that exists.  Do you think that these cards would be as useful if every
> bank issued their own proprietary location of information on the magnetic
> stripe ?
> 
> Smartcards must also develop such standards to make communication to them
> in a seamless manner.  The following is a list of what I consider to be
> necessary for the smartcard industry: 
> 
> 1)  One communication protocol should be used.  Currently there are
> several:  T=0, T=1, Synchronous, and others.  My personal feeling is that
> all cards should communicate in the T=1 block protocol.  It is much more
> efficient, and gives the card a way of communicating back to the reader to
> establish resynchronization or to communicate the need for more waiting
> time.  T=0 does this through the ATR so if the card needs more time it has
> to change the ATR to notify the host of this.   I feel this is a poor way
> of doing this.   
> 
> 2)  The ATR should be used as a means for card identification.  It is
> ridiculous that much of the ATR can be changed except the protocol
> information.  I think the ATR should have 6 historical bytes reserved for
> identification.  2 for manufacturer id, 2 for manufacturer mask, and 2 for
> user definition.  That makes 65,000 manufacturers, 65,000 masks and 65,000
> user defines.  The user can only change their 2 bytes.  Thus the card can
> still be identified by it's core OS 2 bytes manufactuer/2 bytes mask.
>   
> 3)  ISO-7816 should include a command for the creation of a
> transparent file and a command for the listing of files.
> 
> 4)  Card manufacturers need to be ISO compliant.  Class instructions
> should be standardized to either 00 or C0 or whatever.  I should be able
> to list the directory of files on the card in 1 way on any card.
> 
> 5)  There must be a standard for putting the keys on the card.  If RSA is
> used then do pq... whatever but in the same order on each card.  Also,
> cards should have the same endianness.  This is crazy that people haven't
> learned their lessons on this one yet.
> 
> This is just a few for now.  I'll post more as my frustrations build up.
> Is there a forum for these kind of requests ?
> 
> Let me know if you have any suggestions.  I have about 1.5 months off
> right now as I take one class so I should have some free time.
> 
> Hope all is well,
> Dave   
> 
> *
> David Corcoran Internet Security/Smartcards
> 
> Home:  Purdue University
> 1008 Cherry Lane   Department of Computer Science
> West Lafayette, IN 47906   
> Home: (765) 463-0096
> Cell: (317) 514-4797
> 
> http://www.linuxnet.com
> 
> *
> 
> 

RE: MUSCLE Can I distinguish real SC hardware from an emulator?

[DAVID SIMS 1 281 285 7792]

Hi Peter,

  One way of doing this is through a cryptographic handshake... Some cards
(like the Schlumberger Cryptoflex sold in the US) can store a secret key
securely and also do signing on the card... Thus, one side of the
handshake could work like this:

1) reader (or host) gets an X.509v3 cert from the card (publicly available)
2) reader (or host) uses the cert to encrypt a random number and sends it
   to the card
3) card decrypts the number and sends it back to the reader (or host)
4) card can optionally sign the number that is sent back
5) reader (or host) knows that the card is authentic 

Of course, this devolves to the trustedness of the CA that certified the
public key, but that is what public key cryptography is all about
You could reverse this handshake to confirm to the card that the reader
(or host) was authentic... Thus having a bi-directional authentication
handshake. You most likely would be able to use the crypto capability
of the card to encrypt the channel once the handshake is completed
successfully.

Unfortunately, I believe that cards with strong crypto capability are
only available in the USA... but the new java cards (Cyberflex Access)
provide a way of sort of 'beating' the export regulations in that the
cards do not in themselves have crypto capability, but due to the fact
that they have a java runtime environment the crypto stuff may be able
to be done in software that is loaded by the user

For more accurate information about the cards, you may want to contact
Danny Kumamoto <[EMAIL PROTECTED]> or Neville Pattinson
<[EMAIL PROTECTED]>

Dave Sims
**
From:   SMTP%"[EMAIL PROTECTED]"  3-SEP-1999 13:35:08.15
To: SIMS
CC: 
Subj:   MUSCLE Can I distinguish real SC hardware from an emulator?

I'm thinking here about iButtons in particular, but the question is valid
for all authentication tokens, smart cards, etc. Sorry if it's off-topic
by not being Linux specific, but I've yet to find an answer anywhere.

Assuming that I do *not* have control of the hardware into which my SC is
currently plugged via a reader, how can a program (which, e.g. we have
licensed to a client) be sure that it is talking to the genuine SC, and
not an emulator? I really don't care how well tamper proofed the chip is
if, or if it self destructs after 30 days free trial, if I can simply
reproduce an unlimited number of copies in software which will have the
same supposedly "unique" serial number, or have electronic wallets
permanently charged up with credit which never decrements. Anything that
passes along the serial interface can be intercepted and replayed, right?

One answer is if a crypto based key system generates an asymmetric
key pair internally, and never reveals the private key or allows it to be
set I understand that the crypto Java iButton will does this). If the
only traffic out of the SC is signed responses by that key pair and all 
the critical logic is internal, then any traffic on the serial line is
only useful exactly once, which defeats replays. The software must
contain code that checks for the smart card (and cannot easily by
bypassed, which is an art in itself) - and this will be identical for all
instances of the code.

But even if the private key never leaves the SC, the corresponding public
key must be stored *somewhere*, essentially in clear, though possibly
obfuscated, and will be different for each different SC - and clearly any
difference between otherwise identical distributions essentially *is* the
key, and can be replaced with something else that an emulator would
happily accept; back to square one.

I do appreciate that I'm being really *quite* paranoid here, and that
almost anything represents an improvement over current ways of
doing things - essentially nothing. Can come up with characteristics which
would be hard to beat, or is this a fundamentally insoluble problem?

Peter Lister [EMAIL PROTECTED]PGP (RSA): 0xE4D85541
Sychron Ltd  http://www.sychron.com  PGP (DSS): 0xBC1D7258
1 Cambridge Terrace  Voice: +44 1865 200211
Oxford OX1 1UR  UK   FAX:   +44 1865 249666

***
Linux Smart Card Developers - M.U.S.C.L.E.
(Movement for the Use of Smart Cards in a Linux Environment)
http://www.linuxnet.com/smartcard/index.html
***
***
Linux Smart Card Developers - M.U.S.C.L.E.
(Movement for the Use of Smart Cards in a Linux Environment)
http://www.linuxnet.com/smartcard/index.html
***

MUSCLE Has anyone looked at ??

[DAVID SIMS 1 281 285 7792]

Hi,

  There is a good web page at  regarding identity
tokens (and the spec's for them) Has anyone had the opportunity to
look at it with smartcards in mind?? It seems pretty obvious to me that
in order to have *any* application level interoperability (via PKCS 11 or
PC/SC or OCF or CDSA or any of these device specific 'standards') that
there will need to be a consistent file system (and contents) specified
for the card itself independent of the mechanism through which the data
is accessed and which cuts across all of the device connection mechanisms...

  Anyone have thoughts about that???

Dave
***
Linux Smart Card Developers - M.U.S.C.L.E.
(Movement for the Use of Smart Cards in a Linux Environment)
http://www.linuxnet.com/smartcard/index.html
***