[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re[2]: [equinox-dev] Client side security store

Yes, its called keystore and it is pretty bad :-(

Kind regards,

     Peter Kriens

JM> Ok. That makes sense.  We don't need to push the frontiers so
JM> secure storage technology but rather enable our users to use the
JM> stuff built by folks who are.  I'm hoping that there are already
JM> Java APIs for this level of function?

JM> Jeff



JM> BJ Hargrave <hargrave@xxxxxxxxxx>
JM> Sent by: equinox-dev-bounces@xxxxxxxxxxx
JM> 09/23/2005 07:32 AM
JM> Please respond to
JM>  Equinox development mailing list

JM> To
JM> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>cc
JM> Subject
JM> Re: [equinox-dev] Client side security store




JM> I am telling you that w/o hardware (e.g. smartcard, TPM) that it is not
JM>  really secure. If it is just in a file on the harddisk, then it can be
JM>  compromised by software.

JM>  But that is probably all that you are really looking for. If there is a
JM>  secure store in the OS and that is enough for you, then you could provide
JM>  some Java API to front end it.

JM>  BJ Hargrave
JM>  Senior Software Engineer, IBM
JM>  OSGi Fellow and CTO of the OSGi Alliance
JM>  hargrave@xxxxxxxxxx
JM>  Office: +1 407 849 9117 Mobile: +1 386 848 3788



JM>  Jeff McAffer <Jeff_McAffer@xxxxxxxxxx> 
JM>  Sent by: equinox-dev-bounces@xxxxxxxxxxx
JM>  2005-09-22 11:02 PM
JM>  Please respond to
JM>  Equinox development mailing list


JM>  To
JM>  Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
JM>  cc

JM>  Subject
JM>  Re: [equinox-dev] Client side security store







JM>  Are you saying that I don't have a secure store on my XP box?  There must
JM>  be one there somewhere.  If there is, and it has API, then we should be
JM>  able to use it right? 

JM>  Jeff 



JM>  BJ Hargrave <hargrave@xxxxxxxxxx> 
JM>  Sent by: equinox-dev-bounces@xxxxxxxxxxx 
JM>  09/22/2005 10:50 PM 

JM>  Please respond to
JM>  Equinox development mailing list


JM>  To
JM>  Equinox development mailing list <equinox-dev@xxxxxxxxxxx> 
JM>  cc

JM>  Subject
JM>  Re: [equinox-dev] Client side security store








JM>  The only way to get a secure key store is to use hardware like a TPM. You
JM>  will also need a secure JVM, etc...

JM>  BJ Hargrave
JM>  Senior Software Engineer, IBM
JM>  OSGi Fellow and CTO of the OSGi Alliance
JM>  hargrave@xxxxxxxxxx
JM>  Office: +1 407 849 9117 Mobile: +1 386 848 3788



JM>  Jeff McAffer <Jeff_McAffer@xxxxxxxxxx> 
JM>  Sent by: equinox-dev-bounces@xxxxxxxxxxx
JM>  2005-09-22 09:48 PM
JM>  Please respond to
JM>  Equinox development mailing list


JM>  To
JM>  Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
JM>  cc

JM>  Subject
JM>  Re: [equinox-dev] Client side security store







JM>  Thanks Claus for posting that summary.  Between the points made by Claus
JM>  and Peter it seems we could build enough usecases for a secure store on
JM>  the client.  We have had a VERY weak one in Eclipse for years but it is
JM>  only to keep honest people honest. 

JM>  So, the question is, who out there has the necessary knowledge to
JM>  implement or design such a thing.  I assume that most of the building
JM>  blocks are already available.  No? 

JM>  Jeff 



JM>  Peter Kriens <Peter.Kriens@xxxxxxxx> 
JM>  Sent by: equinox-dev-bounces@xxxxxxxxxxx 
JM>  09/21/2005 05:26 AM 

JM>  Please respond to
JM>  Equinox development mailing list


JM>  To
JM>  Claus Nyhus Christensen <cnc@xxxxxxxxxxx> 
JM>  cc
JM>  equinox-dev@xxxxxxxxxxx 
JM>  Subject
JM>  Re: [equinox-dev] Client side security store








JM>  There has been discussions for the OSGi R4 framework to include a
JM>  certificate repository but time did not permit work in this area.

JM>  Any work in this direction is very interesting for OSGi because we
JM>  currently have a several specifications that require certificates but
JM>  we do not have a standardized repository.

JM>  Note that the User Admin has some features that move in the right
JM>  direction, and which are protected with Java 2 security.

JM>  Kind regards,

JM>    Peter Kriens

 CNC>> Hi,

 CNC>> I am currently working on creating an Eclipse RCP front end for the
JM>  J2EE
 CNC>> Adventure Builder Blueprint application
 CNC>> (http://java.sun.com/blueprints). I am doing this work with Nick
JM>  Edgar
 CNC>> and Pascal Rapicault in preparation for a joint tutorial at the JAOO
 CNC>> conference next week.

 CNC>> During this work we discussed client side security. Jeff McAffer got
 CNC>> involved in the discussion, and he asked me to post some of my 
JM>  thoughts
 CNC>> on this mailing list :)

 CNC>> As a start I must say that I am a "J2EE person", i.e. I work for a
JM>  J2EE
 CNC>> vendor and most of my work has been in this field. I have some 
JM>  (minor)
 CNC>> experience with Eclipse RCP, and working with Nick and Pascal really
JM>  got
 CNC>> me hooked on making "fat clients"/Smart Clients for J2EE again.

 CNC>> Well, on to the subject:

 CNC>> Being from the J2EE world I am used to having support for security
 CNC>> functionality in the framework and tools. I can e.g. configure key
JM>  and
 CNC>> trust stores for SSL communication, the browser can cache my username
 CNC>> and password when I log in to a web application and so on. When I
JM>  want
 CNC>> my user interface to be a Smart Client I am more of less on my own.

 CNC>> Therefore, in out opinion Eclipse RCP would benefit greatly from have
 CNC>> some kind of security housekeeping support. In simple scenarios you
JM>  have
 CNC>> to deal with user names and passwords (for different users and 
JM>  different
 CNC>> back end connections). Often you cannot simply cache them on the
 CNC>> connection but have to cache them locally in your program. 
 CNC>> Furthermore, in Denmark digital signatures play a major role (we have

JM>  a
 CNC>> national system where every citizens can get a digital signature
JM>  which
 CNC>> can be used when communicating with the government (tax, health care
JM>  and
 CNC>> so on)) and I expect it to be just as big in other countries. While
 CNC>> digital signatures can be handled pretty easily on the server they
JM>  are
 CNC>> kind of hard to manage on the client side (you have to install them
JM>  in
 CNC>> your trust store and so on).

 CNC>> Based on this we think that it would be really great if Eclipse
 CNC>> RCP had some kind of API and security store for helping to manage
JM>  this.
 CNC>> While a pure Java solution could be developed, we think it would be
 CNC>> better to provide some kind of bridge to the security store of the
 CNC>> operation system, providing for the possibility to share security
 CNC>> settings between applications. On OSX they have something called a
JM>  key
 CNC>> chain, on Linux (Gnome) they have a key ring, and I am sure that
JM>  Windows
 CNC>> has a similar thing. These systems are basically security stores
JM>  where
 CNC>> you can store user names, passwords, digital signatures and then
 CNC>> retrieve them at a later point. Integration with these security
JM>  stores
 CNC>> though a common Eclipse RCP API would in our opinion be a major thing
 CNC>> for client security. I can imagine scenarios where a system
 CNC>> administrator can push digital signatures to security stores on
JM>  client
 CNC>> machines and the RCP applications will then easily be able to use
JM>  them
 CNC>> for connecting to web services and so on.

 CNC>> I do not know that much about these security stores from a technical
 CNC>> point of view, so the above is really just ideas for what we think
JM>  would
 CNC>> be good tools for the programmer to have when dealing with client
JM>  side
 CNC>> security. Maybe it can serve as a starting point for further 
JM>  discussion.

 CNC>> Regards
 CNC>> Claus Nyhus
 CNC>> Trifork



JM>  -- 
JM>  Peter Kriens                              Mob +33633746480
JM>  9C, Avenue St. Drézéry                    Tel +33467542167
JM>  34160 Beaulieu, France                    Tel +15123514821
JM>                                         Tel +33870447986
JM>  AOL,Yahoo, Skype pkriens                  ICQ 255570717

JM>  _______________________________________________
JM>  equinox-dev mailing list
JM>  equinox-dev@xxxxxxxxxxx
JM>  https://dev.eclipse.org/mailman/listinfo/equinox-dev
JM>  _______________________________________________
JM>  equinox-dev mailing list
JM>  equinox-dev@xxxxxxxxxxx
JM>  https://dev.eclipse.org/mailman/listinfo/equinox-dev


JM>  _______________________________________________
JM>  equinox-dev mailing list
JM>  equinox-dev@xxxxxxxxxxx
JM>  https://dev.eclipse.org/mailman/listinfo/equinox-dev
JM>  _______________________________________________
JM>  equinox-dev mailing list
JM>  equinox-dev@xxxxxxxxxxx
JM>  https://dev.eclipse.org/mailman/listinfo/equinox-dev


JM>  _______________________________________________
JM>  equinox-dev mailing list
JM>  equinox-dev@xxxxxxxxxxx
JM>  https://dev.eclipse.org/mailman/listinfo/equinox-dev

  


-- 
Peter Kriens                              Mob +33633746480
9C, Avenue St. Drézéry                    Tel +33467542167
34160 Beaulieu, France                    Tel +15123514821
                                          Tel +33870447986
AOL,Yahoo, Skype pkriens                  ICQ 255570717