Re: [opensc-devel] OpenSC shared mode
On Thu, May 19, 2011 at 1:22 PM, Martin Paljak wrote: > Hello, > > On Mon, May 9, 2011 at 23:22, Alon Bar-Lev wrote: >> This had been raised long ago. >> Create a proxy PKCS#11 that uses another PKCS#11. > p11-kit might be the right tool for this kind of things? Hi, There is no difference between caching the passphrase in a proxy provider, or do this within the OpenSC provider. Both will not work with PINPAD nicely, both will solve the problem for 80% of users. The proxy solution just add more complexity, and be much slower, as it will have to do a full PKCS#11 login/logout every operation. Alon. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC shared mode
Hello, On Mon, May 9, 2011 at 23:22, Alon Bar-Lev wrote: > This had been raised long ago. > Create a proxy PKCS#11 that uses another PKCS#11. p11-kit might be the right tool for this kind of things? http://p11-glue.freedesktop.org/ ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC shared mode
Hello Alon,
On Fri, May 6, 2011 at 20:22, Alon Bar-Lev wrote:
>> For the sake of usability, exclusive mode should only be used *if needed*.
>> From security perspective, it does not really matter, because if your host
>> is compromised, such software tricks are worthless. But daily smart card
>> usage usually means using different applications.
>>
>
> This is incorrect.
> Computer may be compromised in so many levels.
True.
> It is true that if someone has total (root) control over the computer,
> he may do whatever.
> However, other none privileged user MUST NOT be able to gain access to
> resources used by other users.
That's desirable yet not a trivial task. Definition (and enforcement)
of a "current user" in both technical and physical terms is not always
obvious, looking into what has happened with Linux in this world (with
*Kit, device management daemons etc) is IMHO a confession of this, as
it still seems like a moving target. And at what level should this be
enforced? Sometimes a USB flash disk is used as a "personal device"
yet from filesystem it looks like any other path that can have
different permissions. And then there is the question of
interoperability with Windows.
Some systems are designed to be a "single user desktop" even if built
on top of multiuser system, some try to retain multiuser properties.
> Well, you can argue: if I modify the access to readers to a specific
> user, then no other user can access the device anyway.
> If this is enough for users, let it be.
> I don't think it is enough, as this state is not much different than
> using file based cryptographic.
Yes, that's why IMHO a second physical channel (like a pinpad) should
be used if needed. With a PIN entry on the device for every use
tightly controlling access to the key if required. Once you use
cookies, then stealing it from an application and abusing it is
possible, even if made complicated by technological means. For generic
PKI smart cards, in my opinion, priority one is guaranteeing the
secrecy of key material, priority two is controlling access to
operations with the key. Smart card is a physical device that
guarantees key secrecy, pinpad reader (or equivalent physical device,
biometric for example) guarantees access control that is not easy to
tamper with. Everything else is software security.
> I know we do not agree on this, but I have never seen hardware
> cryptography using any similar assumption.
I would not draw a hard border of agreeing/not agreeing :) I just
think that there's a reasonable risk/cost ratio at the moment, as well
as is the situation with other similar "fundamental problems" with PKI
(like embedding secure messaging keys in middleware? why use them at
all in this case?). And that an ultimate solution that would work on
all platforms (and all interfaces, including other than PKCS#11) and
all usage patterns (where there is no "current user" for a token) is
easily doable. Ideas on how to more tightly control access to the
devices while keeping support for multiple applications with multiple
cryptographic APIs are most welcome. But it should work sensibly with
pinpad readers and cards that do not support the mentioned cookie
machinery as well.
What I believe in is providing a real life working solution by default
("Ubuntu style", which manages this nicely by doing some "stupid
things" along the way), with the option of tweaking for setups with
specific requirements or just more paranoid people.
Cheers,
Martin
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC shared mode
2011/5/9 Jean-Michel Pouré - GOOZE : > Dear Alon, > > Could you comment the alternative, where OpenSC would behave as a > client-server application pooling access requests from applications and > locking the card in exclusive mode, i.e. work as a proxy. > > Kind regards, Hi, This had been raised long ago. Create a proxy PKCS#11 that uses another PKCS#11. The proxy does not keep long living session within the proxied PKCS#11 module. This will solve OpenSC issue, however, as it needs to cache the PIN in order to keep opening new session, it will probably lock the card if PIN is changed (same issue as stateless). It will also work extremely slow, as each time it will open session all objects should be enumerated again. And... I don't like proxies... If we going to cache PINs, we need to do so in the OpenSC provider, and solve this at least partially, this way we can also reset all instances if PIN is changed by any OpenSC tool. Alon. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC shared mode
Le samedi 07 mai 2011 à 23:43 +0300, Alon Bar-Lev a écrit : > The authentication cookie solves above, PINPAD, BIO efficiently, > however it requires card to support it. You get a cookie out of > PIN/PINPAD operation/BIO match. The cookie is valid as long as card is > powered on and policy permits. Policy may state that once PIN is > changed all cookies are invalidated or not. You may use the cookie > instead of PIN in all object access operations, so you can use > stateless transactions, while never lock the card by mistake, minimize > the user interaction required during PINPAD/BIO operations. Dear Alon, Could you comment the alternative, where OpenSC would behave as a client-server application pooling access requests from applications and locking the card in exclusive mode, i.e. work as a proxy. Kind regards, -- Jean-Michel Pouré - Gooze - http://www.gooze.eu ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC shared mode
On Sat, May 7, 2011 at 10:57 PM, Peter Stuge wrote: > Alon Bar-Lev wrote: >> However, there are some advanced cards that can generate >> authentication token, so you can actually authenticate once using >> PIN get authentication token out of the card (many can be available >> at same time), then each transaction is authenticated using these >> tokens. This approach solves the PINPAD issue and BIO issues. > > And this works because the p11 library stores these cookies > associated with each "incoming" p11 user? One to one corresponding with C_Login(). This also has the advantage of not locking the card when PIN is changed. If PKCS#11 library caches the PIN, and use it each time to perform card transactions. You have for example Firefox, OpenVPN, GnuPG running. You change the PIN via cmd-line, then each application attempts to sign, each bails out at 1st failure, but after the 3rd accumulative attempt the card is locked. To solve this, the PKCS#11 provider may use some file in /var/tmp to notify all instances when this event occurs so all instances may drop the current PIN. However, this will not work if one use remote sessions, such as remote desktop with PC/SC channel. The authentication cookie solves above, PINPAD, BIO efficiently, however it requires card to support it. You get a cookie out of PIN/PINPAD operation/BIO match. The cookie is valid as long as card is powered on and policy permits. Policy may state that once PIN is changed all cookies are invalidated or not. You may use the cookie instead of PIN in all object access operations, so you can use stateless transactions, while never lock the card by mistake, minimize the user interaction required during PINPAD/BIO operations. Alon. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC shared mode
Alon Bar-Lev wrote: > However, there are some advanced cards that can generate > authentication token, so you can actually authenticate once using > PIN get authentication token out of the card (many can be available > at same time), then each transaction is authenticated using these > tokens. This approach solves the PINPAD issue and BIO issues. And this works because the p11 library stores these cookies associated with each "incoming" p11 user? //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC shared mode
1. Firefox behaves correctly, it opens long living session with crypto token, in order to reduce the number of times user is prompted for passphrase. 2. Firefox monitors slots, to be able to detect new certificate availability so it can prompt the user for one if requested. It is true that it can be done each time a signature operation is required, however, it would be much slower to do so. 3. Firefox may use the monitor (I almost sure it is not implemented) in order to disconnect TLS/SSL sessions once token is removed. --- What PKCS#11 provider should do is to allow single authentication of application while authenticating each transaction with card, aka stateless operation. This approach is problematic with PINPAD readers, as user will be required to enter PIN each operation. However, there are some advanced cards that can generate authentication token, so you can actually authenticate once using PIN get authentication token out of the card (many can be available at same time), then each transaction is authenticated using these tokens. This approach solves the PINPAD issue and BIO issues. Alon. On Sat, May 7, 2011 at 7:08 PM, Juan Antonio Martinez wrote: > > El sáb, 07-05-2011 a las 08:01 +0200, Frank Morgner escribió: > > Hi! > [...] > > In your example, Juan, you say that Firefox calls C_Init to initialize > > the card for pkcs11. I'm not an expert for p11, but is it really needed > > to actually lock the card on initialization and keep an established > > connection? > > Neither I am an expert :-), but my feeling is not: > > Traces on Firefox shows this flow: > > - At starting FF > C_Initialize > C_GetInfo > > - Then ff enters in an infinite loop of: > C_GetSlotList > C_GetSlotInfo > C_WaitForSlotEvent > > - When card is inserted: > C_OpenSession > C_GetSessionInfo > And returns to previou loop > > At exit: > C_CloseAllSessions > C_Finalize > > I can't see a real reason to do any lock for just a simple polling task > nor problem for a concurrent p11 session at this stage > > Moreover, I don't understand why ff needs to monitorize slots when no > p11 task is requested/needed. In fact google says about many links > against this "feature" > > Juan Antonio > > > ___ > opensc-devel mailing list > opensc-devel@lists.opensc-project.org > http://www.opensc-project.org/mailman/listinfo/opensc-devel ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC shared mode
El sáb, 07-05-2011 a las 08:01 +0200, Frank Morgner escribió: > Hi! [...] > In your example, Juan, you say that Firefox calls C_Init to initialize > the card for pkcs11. I'm not an expert for p11, but is it really needed > to actually lock the card on initialization and keep an established > connection? Neither I am an expert :-), but my feeling is not: Traces on Firefox shows this flow: - At starting FF C_Initialize C_GetInfo - Then ff enters in an infinite loop of: C_GetSlotList C_GetSlotInfo C_WaitForSlotEvent - When card is inserted: C_OpenSession C_GetSessionInfo And returns to previou loop At exit: C_CloseAllSessions C_Finalize I can't see a real reason to do any lock for just a simple polling task nor problem for a concurrent p11 session at this stage Moreover, I don't understand why ff needs to monitorize slots when no p11 task is requested/needed. In fact google says about many links against this "feature" Juan Antonio ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC shared mode
Hi! > Many thanks Franck and Martin, using exclusive mode solved my problem: ... > I wonder if there is not a problem in shared more or if we should not > ask users to use exclusive mode only. No problem, I had a similar problem where two applications accessed a smart card. One "initialized" the card leaving it in an unusable state for the other. IMHO, _shared_mode_ is not what you want for multiple applications. What Juan described sounds like a security nightmare. Smart cards do things like mutual authentication, which is not much mutual anymore from the smart cards point of view if applications on the one end can change. If such behaviour is required, applications should at least access the card through the same middleware and let the middleware do SM (and authentication of the different apps). In your example, Juan, you say that Firefox calls C_Init to initialize the card for pkcs11. I'm not an expert for p11, but is it really needed to actually lock the card on initialization and keep an established connection? Cheers, Frank. pgpKKCohNjRW8.pgp Description: PGP signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC shared mode
On 06/05/2011 21:23, Juan Antonio Martinez wrote: > Sure: there are some cases where these approach fails: > SSL renegotiation when signing applet is running; two pkcs11 > trying concurrent access to the card... but this is not > as usual as thought. IMHO you could avoid troubles using a simple state machine: when the "server" sends a command to the card, it sets a busy flag to prevent access from other apps. Once card answers (could take a long time, like when generating an RSA key, but since card is actually "in use" there's no way to avoid it) a timer is started. If another command comes in from the same client, timer gets reset and cycle starts again. If no command is received before timer expires, then card is reset and busy flag is cleared. This way you can be sure that only an active app keeps control of the card. For example, for Firefox it will be like a card removal. It should reread it anyway (maybe a cert got added...). In your example, SSL renegotiation (or signing app) would be delayed the time needed to complete the other operation. An hung app could not lock the card for others. The only drawback I see is that no user intervention is possible during a command sequence: you can't stop to ask PIN, you have to know that a PIN is needed (by parsing PKCS#15 structs or by issuing a crypto op), ask for it and restart sending commands from the beginning. Unless (maybe) if reader comes with a pinpad and its "read PIN" is atomic (that is: no answer till user enters PIN). Or maybe I'm completely gone... :) BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC shared mode
El vie, 06-05-2011 a las 16:43 +0200, Jean-Michel Pouré - GOOZE escribió: > Le vendredi 06 mai 2011 à 17:24 +0300, Martin Paljak a écrit : > > But daily smart card usage usually means using different applications. > > OK. But shared mode does not work very well, especially with OpenSSH and > Iceweasel (Firefox) together. I did some heavy testing and found > usability problems in shared mode. IMHO, shared mode is not usable. > Could someone confirm. Sure me not: For Spanish DNIe shared mode is the _only_ way to get so many applications working: A typical example is an authenticated https connection that loads and run a document signing applet. ( this is a common issue in many gov webpages ) OpenDNIe has an interesting issue related to Secure Messaging and shared mode: DNIe does not support logical channels with separated SM queues for each application. Every concurrent application _must_ share same Secure Channel... So my first approach was to "solve" as you suggested: forbid concurrent applications to make sure that there is only an SM channel at a time. But this approach failed with most of our e-admin public web pages. So exclusive mode is a no-no for me. Second approach was to implement a "secure channel server": divide OpenSC into a client-server application in a way that only the server talks with the reader driver... but too complex, and also found that many apps still try to bypass server and access directly to pcsc :-( So finally my solution was a "collision detector": first app open a card connection and creates an SM channel. When second app starts, some app (or both) receives "SM error" response; then just restart SM and retry. With proper locking this solution work in most tested scenarios... ... Due to the "Init & forget" common approach of most pkcs11 applications: For instance Firefox, calls C_Init at start... and forget pkcs11 until (really) needed. So any signing applet can in turn starts his own pkcs11, restart SM, do the work and call C_finalize. When firefox finally needs to access pkcs11, just receives his own "SM error", restart channel and continues normally Sure: there are some cases where these approach fails: SSL renegotiation when signing applet is running; two pkcs11 trying concurrent access to the card... but this is not as usual as thought. .. About security: I agree: We need some way to ensure that only one user can access to the card at a time Juan Antonio ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC shared mode
On Fri, May 6, 2011 at 5:24 PM, Martin Paljak wrote: > Hello, > > > On May 6, 2011, at 17:16 , Jean-Michel Pouré - GOOZE wrote: >> >> I wonder if there is not a problem in shared more or if we should not >> ask users to use exclusive mode only. > > For the sake of usability, exclusive mode should only be used *if needed*. > From security perspective, it does not really matter, because if your host is > compromised, such software tricks are worthless. But daily smart card usage > usually means using different applications. > This is incorrect. Computer may be compromised in so many levels. It is true that if someone has total (root) control over the computer, he may do whatever. However, other none privileged user MUST NOT be able to gain access to resources used by other users. Well, you can argue: if I modify the access to readers to a specific user, then no other user can access the device anyway. If this is enough for users, let it be. I don't think it is enough, as this state is not much different than using file based cryptographic. I know we do not agree on this, but I have never seen hardware cryptography using any similar assumption. Some References: http://www.mail-archive.com/opensc-devel@lists.opensc-project.org/msg05689.html http://www.opensc-project.org/opensc/ticket/186 http://www.opensc-project.org/pipermail/opensc-devel/2008-December/011525.html http://www.opensc-project.org/pipermail/opensc-user/2008-July/002561.html http://www.opensc-project.org/mailman/private/opensc-internal/2008-June/000335.html Discussion with Nils 5/2008, a prototype option, we agreed this is fundemental problem of the project, but neither had resources to actually solve it. Regards, Alon Bar-Lev. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC shared mode
From a user's prospective, having to shut down an application so another could start is not very friendly. Do we need an tool to force a logoff/unlock/reset/... so a user could start an operation with another application, without having to shutdown the first? With the mini-driver, Windows login will keep keep the mini-driver loaded, not sure what state the card is in, so it also needs to be looked at. On 5/6/2011 9:24 AM, Martin Paljak wrote: > Hello, > > > On May 6, 2011, at 17:16 , Jean-Michel Pouré - GOOZE wrote: >> >> I wonder if there is not a problem in shared more or if we should not >> ask users to use exclusive mode only. > > For the sake of usability, exclusive mode should only be used *if needed*.> > From security perspective, it does not really matter, because if your host is > compromised, such software tricks are worthless. But daily smart card usage > usually means using different applications. > > Best, > Martin -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC shared mode
Le vendredi 06 mai 2011 à 17:24 +0300, Martin Paljak a écrit : > But daily smart card usage usually means using different applications. OK. But shared mode does not work very well, especially with OpenSSH and Iceweasel (Firefox) together. I did some heavy testing and found usability problems in shared mode. IMHO, shared mode is not usable. Could someone confirm. How can I help on my side? Use pkcs11 spy? Kind regards, -- Jean-Michel Pouré - Gooze - http://www.gooze.eu ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC shared mode
Hello, On May 6, 2011, at 17:16 , Jean-Michel Pouré - GOOZE wrote: > > I wonder if there is not a problem in shared more or if we should not > ask users to use exclusive mode only. For the sake of usability, exclusive mode should only be used *if needed*. >From security perspective, it does not really matter, because if your host is compromised, such software tricks are worthless. But daily smart card usage usually means using different applications. Best, Martin -- @MartinPaljak.net +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC shared mode
Le vendredi 06 mai 2011 à 15:41 +0200, Frank Morgner a écrit : > AFAIK, SCardConnect immediately returns an error if an application > wants > to access a reader which is already in exclusive use. Have you tried > switching on exclusive mode in the configuration file of OpenSC? (Note > that this does not completely remove security issues.) Many thanks Franck and Martin, using exclusive mode solved my problem: Running ssh-add first: 1) Run ssh-add -s /usr/lib/opensc-pkcs11.so => Success 2) Start Iceweasel 4 (based on Firefox 4). The security token is not shown ... which is normal as we are in exclusive mode. Iceweasel is started immediately. Running firefox first: 1) Start Iceweasel and login token. Iceweasel is started immediately. 2) ssh-add -s /usr/lib/opensc-pkcs11.so => Failure. Whch is normal as we are in exclusive mode. In exclusive mode, the response is fast, almost instantaneous. In shared mode, I experienced some strange timeouts, waiting for the application to launch. Even when only ONE applications is running. A typical example is ssh-add -s /usr/lib/opensc-pkcs11.so and then run ssh f...@bar.com. In shared more you can wait 12 seconds adding the card and 60 more seconds when using ssh. Or more before anything happens. In exclusive mode, works immediately. Exclusive more: time | ssh-add -s /usr/lib/opensc-pkcs11.so => 8s time | ssh foo@bar ; exit => 4s time | ssh-add -e /usr/lib/opensc-pkcs11.so => 2s Shared mode: time | ssh-add -s /usr/lib/opensc-pkcs11.so => 12s time | ssh foo@bar ; exit => fails 50% of the time or is VERY long. Also, in shared mode, running ssh-add first and then running firefox will block firefox startup. I wonder if there is not a problem in shared more or if we should not ask users to use exclusive mode only. Kind regards, -- Jean-Michel Pouré - Gooze - http://www.gooze.eu ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC shared mode
Hello, On May 6, 2011, at 16:41 , Frank Morgner wrote: >> >> Is there a way to inform opensc-pkcs11.so that a communication is >> already established by Firefox and that SSH should start without using >> pkcs11? > > AFAIK, SCardConnect immediately returns an error if an application wants > to access a reader which is already in exclusive use. Have you tried > switching on exclusive mode in the configuration file of OpenSC? (Note > that this does not completely remove security issues.) It should be possible and it would be a nice feature to have. Figuring out what will happen when the card *will* be available and what to do when a reader is in use by another application is a tricky question though (not all applications can easily reload tokens) lock_login will not result in exclusive mode access to the reader (controlled by "connect_exclusive" configuration option, shared mode by default) but a transaction with SCardBeginTransaction being called on C_Login Cheers, Martin. -- @MartinPaljak.net +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC shared mode
On Friday, May 06 at 03:03PM, Jean-Michel Pouré - GOOZE wrote: > Le vendredi 06 mai 2011 à 14:41 +0300, Martin Paljak a écrit : > > Have a look at the wiki: > > http://www.opensc-project.org/opensc/wiki/SecurityConsiderations > > Sure. > > I am worried about: > * Application A opens communication with token and locks it. > * Application B tries to open communication with token. > * Application B has no knowledge token is locked by application A. No > error message is given. The user waits during minutes, thinking "My > token does not work". > > Is there any mechanism informing an application requesting > opensc-pkcs11.so that a smartcard is locked in exclusive more (=being > accessed)? > To give an example, I could verify: > * Firefox runs, logs in the token in exclusive mode. > * SSH client runs with pkcs11 authentication. SSH client will wait for > minutes until it times out. No specific error message is displayed. > > Is there a way to inform opensc-pkcs11.so that a communication is > already established by Firefox and that SSH should start without using > pkcs11? AFAIK, SCardConnect immediately returns an error if an application wants to access a reader which is already in exclusive use. Have you tried switching on exclusive mode in the configuration file of OpenSC? (Note that this does not completely remove security issues.) Cheers, Frank. pgpzABZh648Lh.pgp Description: PGP signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC shared mode
Le vendredi 06 mai 2011 à 14:41 +0300, Martin Paljak a écrit : > Have a look at the wiki: > http://www.opensc-project.org/opensc/wiki/SecurityConsiderations Sure. I am worried about: * Application A opens communication with token and locks it. * Application B tries to open communication with token. * Application B has no knowledge token is locked by application A. No error message is given. The user waits during minutes, thinking "My token does not work". Is there any mechanism informing an application requesting opensc-pkcs11.so that a smartcard is locked in exclusive more (=being accessed)? To give an example, I could verify: * Firefox runs, logs in the token in exclusive mode. * SSH client runs with pkcs11 authentication. SSH client will wait for minutes until it times out. No specific error message is displayed. Is there a way to inform opensc-pkcs11.so that a communication is already established by Firefox and that SSH should start without using pkcs11? Kind regards, -- Jean-Michel Pouré - Gooze - http://www.gooze.eu ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC shared mode
On 2011-05-06 13:41, Martin Paljak wrote: > > On May 5, 2011, at 23:02 , Jean-Michel Pouré - GOOZE wrote: > >> Dear all, >> >> Some simple questions: >> >> When used with lock_login = false; >> authenticated tokens are available for all users. >> >> For knowledge, what would be the technical solution to secure access in >> shared mode? > > > Have a look at the wiki: > > http://www.opensc-project.org/opensc/wiki/SecurityConsiderations "If keys on the card are left in authorized state, another application could misuse the keys" I'm happy that I opted for stateless operation in SKS for "using" keys and fully concurrent mode featuring SM for "provisioning" keys. No reason ever for locking (up) or fiddling with "config" files. Anders ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC shared mode
On May 5, 2011, at 23:02 , Jean-Michel Pouré - GOOZE wrote: > Dear all, > > Some simple questions: > > When used with lock_login = false; > authenticated tokens are available for all users. > > For knowledge, what would be the technical solution to secure access in > shared mode? Have a look at the wiki: http://www.opensc-project.org/opensc/wiki/SecurityConsiderations -- @MartinPaljak.net +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] OpenSC shared mode
Dear all, Some simple questions: When used with lock_login = false; authenticated tokens are available for all users. For knowledge, what would be the technical solution to secure access in shared mode? 1) Previously, we discussed about a proxy which would lock access to smartcard. Users would authenticate against this proxy using PIN code. Right? 2) Or is there any pkcs#15 mechanism allowing shared mode and still PIN code authentication? 3) Or any other solution? Kind regards, -- Jean-Michel Pouré - Gooze - http://www.gooze.eu ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
