To NSS-Java or not to NSS-Java, thats the question.

[helpcrypto helpcrypto]

Hi all [Opening my pandora...].

A few months ago we started having problems with NSS (and OSX):

-Cannot load NSS libs from applet on Firefox 4 on MacOSX
http://forums.mozillazine.org/viewtopic.php?f=38&t=2165273
-Firefox 4 bad initialize on Mac OSX 10.6.7 This cause wrong
java.library.path, user.dir and @executable_path for Java libraries
(NSS/JSS)
https://bugzilla.mozilla.org/show_bug.cgi?id=654939
-Use @loader_path instead of @executable_path in internal name of
dylibs (Fix OSX support of Java-NSS)
https://bugzilla.mozilla.org/show_bug.cgi?id=578751

IMHO, this is some that needs some clarification, as Mozilla *IS*
supporting it developing JSS but at the same time saying "we do not
support it", and other options dont work properly due to some bugs
that need to be fixed...or not. Google Chrome works well and is taking
some advantage on this feature (too).
If we want Firefox to be used widely on bussiness/enterprise, then it
will be necessary to take an "official position", so PLEASE answer or
discuss the following:

-Does mozilla *WANT* Java use certificates stored on NSS to do
document signning?
-What about Java applets?
-Is mozilla going to *AVOID* Java use certificates, or consider this
as an "undocumented/undesired behaviour"?
-What about Java applets?
-Supporting this (or document sign with XAdES or any other advanced
systems) is one of mozilla's targets?
-Will patches which fix this issues merged (if correct) in branch, or
will they become marked as WONTFIX?

We dont want to rely on "undocumented/undesired" behaviour, and will
like to discuss whats the "official opinion" on this.

Consider the following example:
Signning a document with XAdES format with a certificate stored on NSS.
Can it be done? How should it be done?

[helpcrypto helpcrypto]

[Brian Smith]

helpcrypto helpcrypto wrote:
> IMHO, this is some that needs some clarification, as Mozilla *IS*
> supporting it developing JSS but at the same time saying "we do not
> support it",

Some people who are part of the Mozilla project maintain JSS. I will help review patches to JSS if/when the members of the NSS team that want to continue supporting JSS ask me to. That is as much enthusiasm for JSS as you are likely to get from Mozilla employees.

> and other options dont work properly due to some bugs
> that need to be fixed...or not. Google Chrome works well and is
> taking some advantage on this feature (too).

Google Chrome is exposing NSS to Java/JSS on Mac OS X? I did not think that Chrome uses the NSS certificate database at all on Mac OS X.

> -Does mozilla *WANT* Java use certificates stored on NSS to do
> document signning?
> -What about Java applets?
> -Is mozilla going to *AVOID* Java use certificates, or consider this
> as an "undocumented/undesired behaviour"?
> -What about Java applets?

We already expose window.crypto.signText which supposedly will sign documents using certificates stored in NSS on all *desktop* Firefox versions. This should be accessible from Java via the Java-JS bridge that I know nothing about.

> -Supporting this (or document sign with XAdES or any other advanced
> systems) is one of mozilla's targets?

In Firefox and Thunderbird? No.

> -Will patches which fix this issues merged (if correct) in branch, or
> will they become marked as WONTFIX?

It depends on whether the bug is in JSS, NSS, Gecko, and what exactly the bug is, and how complex the patch is. If you provide more details of what doesn't work, we can discuss whether it is reasonable to try to fix it.

> We dont want to rely on "undocumented/undesired" behaviour, and will
> like to discuss whats the "official opinion" on this.

I cannot tell you an official opinion but I would say that I personally would not bet any money on depending on Java + NSS integration to work reliably in Firefox, because that would be a very low priority for most Gecko developers.

> Consider the following example:
> Signning a document with XAdES format with a certificate stored
> on NSS.
> Can it be done?

I am not sure.

> How should it be done?

I am not sure how to solve whatever problems you are having in the short term.

In the long term:

1. Write patches that replace the usage of NSS in Firefox with usage of the system certificate store for client certificates.
2. Help specify and develop the DOMCrypt JS API in Firefox, including integration of DOMCrypt with the system certificate store.
3. Rewrite the applet in JS. If you can't, then have your Java application use the JS<->Java API we have to use the DOMCrypt JS API to sign your documents.

I noticed that you seem to be considering reading the NSS keyX.db and certX.db files from Java directly. Keep in mind that it is not supported to access these files directly, that these files may change format at any time (e.g. Red Hat would like Firefox and Thunderbird to switch to the SQLite-based format), and that hopefully Firefox and Thunderbird will eventually stop using these NSS certificate databases completely except on Linux. None of those things will happen any time soon, but I expect them all to happen eventually.

Cheers,
Brian

[Brian Smith]

[Robert Relyea]

On 04/04/2012 04:30 PM, Brian Smith wrote:
> helpcrypto helpcrypto wrote:
>> IMHO, this is some that needs some clarification, as Mozilla *IS*
>> supporting it developing JSS but at the same time saying "we do not
>> support it",
> Some people who are part of the Mozilla project maintain JSS. I will help review patches to JSS if/when the members of the NSS team that want to continue supporting JSS ask me to. That is as much enthusiasm for JSS as you are likely to get from Mozilla employees.

You want to talk to Matthew Harmsen. I believe he's the new maintainer
of JSS.

bob

[helpcrypto helpcrypto]

> Google Chrome is exposing NSS to Java/JSS on Mac OS X? I did not think that Chrome uses the NSS certificate database at all on Mac OS X.

Google chrome use each OS specific keystore. On OSX its keychain, so
theres no need of JSS. In Linux, and using shared nss db, it uses jss
and works "well".

>> -Does mozilla *WANT* Java use certificates stored on NSS to do document signning?
>> -What about Java applets?
>> -Is mozilla going to *AVOID* Java use certificates, or consider this as an "undocumented/undesired behaviour"?
>> -What about Java applets?

(Still not awswered)

> We already expose window.crypto.signText which supposedly will sign documents using certificates stored in NSS on all *desktop* Firefox versions. This should be accessible from Java via the Java-JS bridge that I know nothing about.

And, IMHO, this is NOT enough BY FAR to accomplish the bussiness needs.
Anyhow, IMVHO, doing different code for different OS/platform is worse
(and less portable) than using Java Providers and Java-NSS should be
supported

>> -Will patches which fix this issues merged (if correct) in branch, or will they become marked as WONTFIX?
> It depends on whether the bug is in JSS, NSS, Gecko, and what exactly the bug is, and how complex the patch is. If you provide more details of what doesn't work, we can discuss whether it is reasonable to try to fix it.

Example: https://bugzilla.mozilla.org/show_bug.cgi?id=578751
(This bug fix could solve many of the problems we have with NSS+OSX)

> I cannot tell you an official opinion but I would say that I personally would not bet any money on depending on Java + NSS integration to work reliably in Firefox, because that would be a very low priority for most Gecko developers.

The question can be changed to:
-Do mozilla want companies and bussiness to use Firefox? (rather than chrome)
-Do mozilla think themes and make up are more important to bussines
than this kind of features?

> In the long term:
>
> 1. Write patches that replace the usage of NSS in Firefox with usage of the system certificate store for client certificates.

So, you are "open to stop using NSS", instead od keychain/cryptoapi?
Glad to hear :)

> 2. Help specify and develop the DOMCrypt JS API in Firefox, including integration of DOMCrypt with the system certificate store.

Going to contact workgroup, but developing a new API (for Firefox
only) doesnt solve the problem, just create another one: Support the
old+new API.

> 3. Rewrite the applet in JS. If you can't, then have your Java application use the JS<->Java API we have to use the DOMCrypt JS API to sign your documents.

Java was created and designed to be cross-platform. Doing such a thing
makes java become a wrapper to "propietary" solutions, instead of
making portability a fact. Same for doing a JS for firefox. I prefer
option 1.

> I noticed that you seem to be considering reading the NSS keyX.db and certX.db files from Java directly.

Not totally correct. I have been "forced" to parse secmod.db, cause
Java interface to secmod doesnt seem to work properly (I have to file
a few bugs to Oracle)

> Keep in mind that it is not supported to access these files directly, that these files may change format at any time (e.g. Red Hat would like Firefox and Thunderbird to switch to the SQLite-based format), and that hopefully Firefox and Thunderbird will eventually stop using these NSS certificate databases completely except on Linux. None of those things will happen any time soon, but I expect them all to happen eventually.

Again, glad to hear (specially the sqlite part).
Why RedHat "would like" -> "mozilla switch"?

Thans a lot for your time and pacience, Brian.

PS: Thanks Robert for the matthew contact. ;)

[Gen Kanai]

On 4/9/12 6:05 PM, helpcrypto helpcrypto wrote:
> The question can be changed to:
> -Do mozilla want companies and bussiness to use Firefox? (rather than chrome)
> -Do mozilla think themes and make up are more important to bussines
> than this kind of features?

If you are familiar with the Mozilla project and the history of Firefox,
Mozilla has always been focused on the end user.

We know that many enterprises do deploy Firefox but our product
decisions are clearly not based on the needs of enterprise IT managers.

It's not that we don't care about the enterprise market. We do. We
recently worked to develop an extended support version of Firefox for
that segment when it was clear that the rapid-release model was
impossible for enterprises. However, we are a small non-profit and we
need to set priorities and focus our resources. We can't do everything.

If you'd like to help make Firefox better for enterprises, we'd be
delighted to have you submit patches instead of questioning our
commitment to our users.

--
Gen Kanai

[Anders Rundgren]

Using Java with NSS is something I don't believe is a good idea for
applets. IMO it is Oracle's call creating useful key-store mechanisms
for the different platforms. So far they have only done that for Windows.

Mozilla+Redhat OTOH, ought to rework the *NIX keystore so that it one
day actually matches what Windows have had since 95 or 98. Static
libraries do not represent the future; Google use services in Android 4 and
this is where the rest of the industry is going as well.

Anders

[helpcrypto helpcrypto]

>> If you'd like to help make Firefox better for enterprises, we'd be
>> delighted to have you submit patches instead of questioning our
>> commitment to our users.

I'll ask another way: Is there any argument against compiling NSS with
@loader_path instead of current @executable_path?
(https://bugzilla.mozilla.org/show_bug.cgi?id=578751)

> Using Java with NSS is something I don't believe is a good idea for applets.

Why is not a good idea? Do you know a better way of doing a XAdES-XL?
Anyway, if JSS is for java local apps, rather than Applets, that
should appear on JSS documentation.

> IMO it is Oracle's call creating useful key-store mechanisms
> for the different platforms. So far they have only done that for Windows.

Java can work with PKCS#12, PKCS#11, SunMSCAPI, OSX Keychain and NSS
(with a few bugs, as you can see).
The question here is: Can Oracle invoke NSS?

Quoting bsmedberg (https://bugzilla.mozilla.org/show_bug.cgi?id=654939#c19):
"No, writing enterprise apps which poke into the Firefox certificate
store is not a desired use-case"

Is that the official position?

[Anders Rundgren]

On 2012-04-16 09:47, helpcrypto helpcrypto wrote:
>>> If you'd like to help make Firefox better for enterprises, we'd be
>>> delighted to have you submit patches instead of questioning our
>>> commitment to our users.
>
> I'll ask another way: Is there any argument against compiling NSS with
> @loader_path instead of current @executable_path?
> (https://bugzilla.mozilla.org/show_bug.cgi?id=578751)

I would not build a scheme based on NSS because NSS is not a
prerequisite unless you force people to use Firefox.

Even if JSS works, it simply cannot be high-priority task for
Mozilla keeping this in shape. Hooking Mozilla/NSS into native
APIs like CryptoAPI is a much more important task.

I don't really see the link between XadES-XL and key-stores.

The Windows key-store is probably more secure than NSS since the
former is running at OS-level.

Anders

[Anders Rundgren]

On 2012-04-17 09:06, helpcrypto helpcrypto wrote:
>> I would not build a scheme based on NSS because NSS is not a prerequisite unless you force people to use Firefox.

> We arent forcing. We already support Microsoft, OSX and Google
> browsers, and (trying) Firefox too.

>
>> Hooking Mozilla/NSS into native APIs like CryptoAPI is a much more important task.

> IIUC...will someday Mozilla hook NSS with System (Windows or OSX)?

Mozilla is also actively trying to establish Firefox in mobile devices.
In such devices you do not really have any choice but accepting the platforms
native key store scheme. Anything else would be foolish.

Anders

>
>>> Quoting bsmedberg (https://bugzilla.mozilla.org/show_bug.cgi?id=654939#c19):
>>> "No, writing enterprise apps which poke into the Firefox certificate store is not a desired use-case"

> Is that the official Mozilla position?

>
>>> I'll ask another way: Is there any argument against compiling NSS with
>>> @loader_path instead of current @executable_path?
>>> (https://bugzilla.mozilla.org/show_bug.cgi?id=578751)

> Will patches be accepted (if correct), or "some people" want
> @executable_path, rather than @loader_path ?

[helpcrypto helpcrypto]

So, do you (we) ALL agree NSS should be modified to hook with system
keystores like Windows or OSX? (Linux has no default system keystore,
so there will be no changes by now)
Maybe wtc has something to say against this...

Are mozilla (we) going to see (wait) whats is said on:
http://www.w3.org/2011/11/webcryptography-charter.html ?

[ianG]

It - how crypto-apis are designed and interface with their apps - is a
very vexatious question. There are no right answers nor easy answers.
I'm interested as much as others to see how this one pans out...


iang

[Anders Rundgren]

On 2012-04-17 11:14, helpcrypto helpcrypto wrote:
> So, do you (we) ALL agree NSS should be modified to hook with system
> keystores like Windows or OSX? (Linux has no default system keystore,
> so there will be no changes by now)
> Maybe wtc has something to say against this...
>
> Are mozilla (we) going to see (wait) whats is said on:
> http://www.w3.org/2011/11/webcryptography-charter.html ?

I participated both in a workshop in Mountain View as well as
in some of the early discussions in a mailing-list.

I got the impression that the proposers do not completely understand
the difference between exposing APIs to untrusted browser-code versus APIs
that are only available to built-in or explicitly installed plugin code.

It was for example suggested that PKCS #11 should be exposed as a
JavaScript object. I think that is downright ridiculous idea,
almost as bad as: http://www.sconnect.com/FAQ/index.html

Making Firefox compliant with Windows and OSX keystores is IMO an
entirely different task.

Anders

[helpcrypto helpcrypto]

> It was for example suggested that PKCS #11 should be exposed as a
> JavaScript object.  I think that is downright ridiculous idea,
> almost as bad as: http://www.sconnect.com/FAQ/index.html

Let me expose two user-cases where i think that will be helpfull (and
maybe the only option).

-Web page that allows company users to request a certificate WITHIN
company smartcard:
User inserts smartcard, click request, connection to pkcs#11 is
made, if card present, all the operation can be done.

Otherwise (current), request is done "somewhere". If a card is
present, a dialog (where the user can mistake and select the bad
crypto device) is shown, otherwise is requested on softokn. We dont
have any control if certificate is on card or softoken :(

-I want to establish a secure conversation between my server and an
smartcard like european ids, knowing im talking with a valid secure
device (like Spanish DNIe secure channel)

> Making Firefox compliant with Windows and OSX keystores is IMO an
> entirely different task.

Indeed it is.


So, IMHO there are 2 milestones:
-Make NSS work with CryptoAPI/Keychain / Linux?
-Export a PKCS#11/15 javascript API to communicate with any
cryptographic device. (This+OpenSC=everything working everywhere!)

Anders, I'll like to hear why you consider that (PKCS#11) a "downright
ridiculous idea".

[Anders Rundgren]

On 2012-04-17 14:14, helpcrypto helpcrypto wrote:
>> It was for example suggested that PKCS #11 should be exposed as a
>> JavaScript object. I think that is downright ridiculous idea,
>> almost as bad as: http://www.sconnect.com/FAQ/index.html
>
> Let me expose two user-cases where i think that will be helpfull (and
> maybe the only option).
>
> -Web page that allows company users to request a certificate WITHIN
> company smartcard:
> User inserts smartcard, click request, connection to pkcs#11 is
> made, if card present, all the operation can be done.
>
> Otherwise (current), request is done "somewhere". If a card is
> present, a dialog (where the user can mistake and select the bad
> crypto device) is shown, otherwise is requested on softokn. We dont
> have any control if certificate is on card or softoken :(
>
> -I want to establish a secure conversation between my server and an
> smartcard like european ids, knowing im talking with a valid secure
> device (like Spanish DNIe secure channel)

Although E2ES (End-to-End-Security with respect to the *container*) is
actually my line of work (http://webpki.org/papers/keygen2/sks-api-arch.pdf),
I don't understand why you would use it during signing or authentication.
Yes, TLS-client-cert-authentication is also E2ES but it works "one level up".

During enrollment you may want to verify that the device you are talking to
is "genuine" or not. After enrollment you do not need to repeat this because
the policy expressed though the enrolled certificate should implicitly or
explicitly provide this information to the relying party.

There may surely be something in the Spanish scheme which I don't know about,
but I suspect that whatever it may be, it is probably a bit "unusual" :-)
Feel free enlighten me!

>
>> Making Firefox compliant with Windows and OSX keystores is IMO an
>> entirely different task.
>
> Indeed it is.

Good.

>
>
> So, IMHO there are 2 milestones:
> -Make NSS work with CryptoAPI/Keychain / Linux?
> -Export a PKCS#11/15 javascript API to communicate with any
> cryptographic device. (This+OpenSC=everything working everywhere!)
>
> Anders, I'll like to hear why you consider that (PKCS#11) a "downright
> ridiculous idea".

Microsoft's "CertEnroll" solution exposes quite a bunch of sensitive APIs.
This creates an awful lot of security and privacy-related dialogs which no normal
user can possibly understand. I call it "Epic Fail" :-)

Exposing NSS, PKCS #11 or PC/SC to downloaded browser code suffers from the same issues.

Anders

[Martin Paljak]

On Tue, Apr 17, 2012 at 16:05, Anders Rundgren
<anders....@telia.com> wrote:

> Exposing NSS, PKCS #11 or PC/SC to downloaded browser code suffers from the same issues.

All the mentioned interfaces are the lowest common denominators to
some extent. Also, provisioning shall suffer from lack of interest
from involved (software vendor) parties, as it accounts for 0.00X% of
"planned usage" for tokens or devices and to date, provisioning has
been 80% vendor-lock-in business.

Nevertheless, I've been following the webpki thing with interest, I
believe it is going in the right direction :)

Martin

[helpcrypto helpcrypto]

> Although E2ES (End-to-End-Security with respect to the *container*) is
> actually my line of work (http://webpki.org/papers/keygen2/sks-api-arch.pdf),
> I don't understand why you would use it during signing or authentication.
> Yes, TLS-client-cert-authentication is also E2ES but it works "one level up".

So, simplified: "authentication is done using certificates", no matter
if on smartcard or softokn. Isnt it?

> During enrollment you may want to verify that the device you are talking to
> is "genuine" or not.

During enrollment, i need to know card is present and the keypair is
generated inside. how can i achieve this without a pkcs#11 interface?

>  After enrollment you do not need to repeat this because
> the policy expressed though the enrolled certificate should implicitly or
> explicitly provide this information to the relying party.

So, our policy says: certs are always generated inside the smartcard, isnt it?.
Thats not our case. We use an "official"(sorry for that) FNMT (sorry
again) certs that is "imported" to the card.

Anyhow, how can we control the card without a pkcs#11 interface?

> There may surely be something in the Spanish scheme which I don't know about,
> but I suspect that whatever it may be, it is probably a bit "unusual" :-)
> Feel free enlighten me!

Nothing unusual, AFAIK. Spanish DNIe is just a securte crypto card
where keypairs are not extractable/writable, generated inside and
where communications are done using a secure channel. The card has a
"component certificate" to show its a real DNIe.
More info: http://www.opensc-project.org/opensc/wiki/DNIe

> Microsoft's "CertEnroll" solution exposes quite a bunch of sensitive APIs.
> This creates an awful lot of security and privacy-related dialogs which no normal
> user can possibly understand. I call it "Epic Fail" :-)

CISC vs. RISC.
I think PKCS#11 its not so awful and will not be an epic fail.

> Exposing NSS, PKCS #11 or PC/SC to downloaded browser code suffers from the same issues.

I agree PC/SC is "too low" to be ok.
Softokn and other PKCS#11 crypto devices can be controlled by PKCS#11
api, and this is IMVHO the correct option to control devices. (having
a well-sized/defined API).

Must be a translation issue + my lack of english skills, but i dont
feel you answered my previous and current question:
how can i work with a smartcard without a pkcs#11 interface?

[Anders Rundgren]

Dear "helpcrypto", now it became a little bit messy because I'm talking about
principles while you are talking about specific interfaces like NSS, and PKCS #11.

> During enrollment, i need to know card is present and the keypair is
> generated inside. how can i achieve this without a pkcs#11 interface?

None of the popular cryptographic APIs support container attestations.
None of the PKIX enrollment protocols support container attestations.
Container attestations must be performed at the APDU-level since
E2ES cannot be "abstracted".

Redhat supports container attestations (aka Secure Messaging) in their
"DogTag" card management product. This part does not rely on PKCS #11.

>> Microsoft's "CertEnroll" solution exposes quite a bunch of sensitive APIs.
>> This creates an awful lot of security and privacy-related dialogs which no normal
>> user can possibly understand. I call it "Epic Fail" :-)
>
> CISC vs. RISC.
> I think PKCS#11 its not so awful and will not be an epic fail.

Are we actually talking about the same thing here? I'm talking about
exposing cryptographic APIs to code running in an arbitrary web page.
This is what CertEnroll does and that is an *extremely* bad idea.

Compare this with HTTPS which can be invoked from any page without
exposure of a single cryptographic method. That's a good system.

I still don't understand the Spanish use-case and particularly not
why you need card-level Secure Messaging for signing data. I guess
it is also about the server authenticating to the card?

Anders

[helpcrypto helpcrypto]

On Wed, Apr 18, 2012 at 10:03 AM, Anders Rundgren
<anders....@telia.com> wrote:
> Dear "helpcrypto", now it became a little bit messy because I'm talking about
> principles while you are talking about specific interfaces like NSS, and PKCS #11.

Ok. Rather than discussing technical or theorical point of views, i
think we could start focusing on "what the user need and how can we do
it" possible(design/implementation).

>> During enrollment, i need to know card is present and the keypair is
>> generated inside. how can i achieve this without a pkcs#11 interface?
>
> None of the popular cryptographic APIs support container attestations.
> None of the PKIX enrollment protocols support container attestations.

Using CryptoAPI you can select which CSP to work with, and a CSP can
point to a specific smartcard.
If the keys are generated inside the card i dont need a PKIX
enrollment protocol that support anything special, cause im sure the
keys are generated on the right place.

> Container attestations must be performed at the APDU-level since E2ES cannot be "abstracted".

I dont understand that.

Again: lets try (both) to leave the theorical/technical, and think in
what the user needs.

> Are we actually talking about the same thing here?  I'm talking about
> exposing cryptographic APIs to code running in an arbitrary web page.
> This is what CertEnroll does and that is an *extremely* bad idea.

Consider: I want a user to be able to request a certificate on our
company smartcard.
Is that an "*extremely* bad idea"?

If you think is not, lets focus on the problem itself: how to request
a certificate within a smartcard
If you think is it...could you tell me why?

> Compare this with HTTPS which can be invoked from any page without
> exposure of a single cryptographic method.  That's a good system.

I really this understand this. You think "a protocol" is the solution?

> I still don't understand the Spanish use-case and particularly not
> why you need card-level Secure Messaging for signing data.  I guess
> it is also about the server authenticating to the card?

Seems the DNIe doesnt help to clear the problems im having. Forget the
example and try to focus on the "detect anc work with the smartcard"
issue.

[Anders Rundgren]

On 2012-04-18 11:04, helpcrypto helpcrypto wrote:
> On Wed, Apr 18, 2012 at 10:03 AM, Anders Rundgren
> <anders....@telia.com> wrote:
>> Dear "helpcrypto", now it became a little bit messy because I'm talking about
>> principles while you are talking about specific interfaces like NSS, and PKCS #11.
>
> Ok. Rather than discussing technical or theorical point of views, i
> think we could start focusing on "what the user need and how can we do
> it" possible(design/implementation).
>
>>> During enrollment, i need to know card is present and the keypair is
>>> generated inside. how can i achieve this without a pkcs#11 interface?
>>
>> None of the popular cryptographic APIs support container attestations.
>> None of the PKIX enrollment protocols support container attestations.
>
> Using CryptoAPI you can select which CSP to work with, and a CSP can
> point to a specific smartcard.
> If the keys are generated inside the card i dont need a PKIX
> enrollment protocol that support anything special, cause im sure the
> keys are generated on the right place.

My scenario is a billion+ community who haven't a clue what a CSP
is and never will. They may not even know what a certificate is!

A CSP-solution doesn't give the issuer any information about where and
how a key was generated. The same goes for NSS, JCE, and PKCS #11.

>> Container attestations must be performed at the APDU-level since
>> E2ES cannot be "abstracted".
>
> I dont understand that.

See section 9.5 of:
http://forja.cenatic.es/docman/view.php/160/684/cwa14890-01-2004-Mar.pdf

I have taken another path than ISO/CEN but both concepts stem from the same root:
http://openkeystore.googlecode.com/svn/trunk/resources/docs/Efficient-Provisioning-of-Complex-Structures-Over-Unsecured-Channels.pdf

As can be seen from the documents, Secure Messaging isn't something you could
bring up on a typical cocktail party :-) :-)

> Again: lets try (both) to leave the theorical/technical, and think in
> what the user needs.
>
>> Are we actually talking about the same thing here? I'm talking about
>> exposing cryptographic APIs to code running in an arbitrary web page.
>> This is what CertEnroll does and that is an *extremely* bad idea.
>
> Consider: I want a user to be able to request a certificate on our
> company smartcard.
> Is that an "*extremely* bad idea"?

If it works like "CertEnroll" or "SConnect" it is indeed an extremely
bad idea because it exposes the card to accesses by untrusted parties.

> If you think is not, lets focus on the problem itself: how to request
> a certificate within a smartcard
> If you think is it...could you tell me why?
>
>> Compare this with HTTPS which can be invoked from any page without
>> exposure of a single cryptographic method. That's a good system.
>
> I really this understand this. You think "a protocol" is the solution?

Almost. I started years ago with a protocol and later realized that
secure messaging must be a part of that. However, given the weirdness
of smart cards, I found that you would also need a carefully matching
container in order to ever get it supported inside a standard browser.

>> I still don't understand the Spanish use-case and particularly not
>> why you need card-level Secure Messaging for signing data. I guess
>> it is also about the server authenticating to the card?
>
> Seems the DNIe doesnt help to clear the problems im having. Forget the
> example and try to focus on the "detect anc work with the smartcard"
> issue.

Regards,
Anders

[ianG]

(lo-pri interest only requests)

On 18/04/12 20:00 PM, Anders Rundgren wrote:
> On 2012-04-18 11:04, helpcrypto helpcrypto wrote:

>>> Container attestations must be performed at the APDU-level since
>>> E2ES cannot be "abstracted".
>>
>> I dont understand that.
>
> See section 9.5 of:
> http://forja.cenatic.es/docman/view.php/160/684/cwa14890-01-2004-Mar.pdf
>
> I have taken another path than ISO/CEN but both concepts stem from the same root:
> http://openkeystore.googlecode.com/svn/trunk/resources/docs/Efficient-Provisioning-of-Complex-Structures-Over-Unsecured-Channels.pdf
>
> As can be seen from the documents, Secure Messaging isn't something you could
> bring up on a typical cocktail party :-) :-)

Hmm... I haven't read your cocktail books above, but do you have a
minimalist recipe? What's a Secure Message? In explanatory terms.

...

>>> Are we actually talking about the same thing here? I'm talking about
>>> exposing cryptographic APIs to code running in an arbitrary web page.
>>> This is what CertEnroll does and that is an *extremely* bad idea.
>>
>> Consider: I want a user to be able to request a certificate on our
>> company smartcard.
>> Is that an "*extremely* bad idea"?

(to me, that question makes no sense. users can't talk to smart cards.
Only smart card readers and programs can. So what smart card reader
and what program is doing this? A dumb smart card reader and a browser,
following Javascript instructions from a website? That'd be game over...)

...

>>> Compare this with HTTPS which can be invoked from any page without
>>> exposure of a single cryptographic method. That's a good system.
>>
>> I really this understand this. You think "a protocol" is the solution?
>
> Almost. I started years ago with a protocol and later realized that
> secure messaging must be a part of that.

curious ... (smart card) money products also work this way. That is, at
its base layer, peers talk with secure messaging. Once you've got that
layered in as the core design, the rest is easy (handwave handwave)...
they problem is that most designs don't get that right, and struggle.

Although, maybe I'm reading more into "secure message" than is meant.

> However, given the weirdness
> of smart cards, I found that you would also need a carefully matching
> container in order to ever get it supported inside a standard browser.

Well, using my view of a secure message, the conceptual browser can't be
a peer. So all it can do is do packet routing.

But, real-world browsers don't do that, they pretend to be the only
peer, and that's where the trouble starts.



iang

[Anders Rundgren]

On 2012-04-18 13:06, ianG wrote:
> (lo-pri interest only requests)

Short return then :-)

>
> On 18/04/12 20:00 PM, Anders Rundgren wrote:
>> On 2012-04-18 11:04, helpcrypto helpcrypto wrote:
>
>>>> Container attestations must be performed at the APDU-level since
>>>> E2ES cannot be "abstracted".
>>>
>>> I dont understand that.
>>
>> See section 9.5 of:
>> http://forja.cenatic.es/docman/view.php/160/684/cwa14890-01-2004-Mar.pdf
>>
>> I have taken another path than ISO/CEN but both concepts stem from the same root:
>> http://openkeystore.googlecode.com/svn/trunk/resources/docs/Efficient-Provisioning-of-Complex-Structures-Over-Unsecured-Channels.pdf
>>
>> As can be seen from the documents, Secure Messaging isn't something you could
>> bring up on a typical cocktail party :-) :-)
>
>
> Hmm... I haven't read your cocktail books above, but do you have a
> minimalist recipe? What's a Secure Message? In explanatory terms.

In the SC-world it is a secure channel between "something" and the card.

>
> ...
>>>> Are we actually talking about the same thing here? I'm talking about
>>>> exposing cryptographic APIs to code running in an arbitrary web page.
>>>> This is what CertEnroll does and that is an *extremely* bad idea.
>>>
>>> Consider: I want a user to be able to request a certificate on our
>>> company smartcard.
>>> Is that an "*extremely* bad idea"?
>
>
> (to me, that question makes no sense. users can't talk to smart cards.
> Only smart card readers and programs can. So what smart card reader
> and what program is doing this? A dumb smart card reader and a browser,
> following Javascript instructions from a website? That'd be game over...)

Exactly my point. Microsoft's "solution" to this is annoying the user
with dialogs like "this site wants enumerate your keystore, do you accept?"

> ...
>>>> Compare this with HTTPS which can be invoked from any page without
>>>> exposure of a single cryptographic method. That's a good system.
>>>
>>> I really this understand this. You think "a protocol" is the solution?
>>
>> Almost. I started years ago with a protocol and later realized that
>> secure messaging must be a part of that.
>
> curious ... (smart card) money products also work this way. That is, at
> its base layer, peers talk with secure messaging. Once you've got that
> layered in as the core design, the rest is easy (handwave handwave)...
> they problem is that most designs don't get that right, and struggle.
>
> Although, maybe I'm reading more into "secure message" than is meant.
>
>> However, given the weirdness
>> of smart cards, I found that you would also need a carefully matching
>> container in order to ever get it supported inside a standard browser.
>
>
> Well, using my view of a secure message, the conceptual browser can't be
> a peer. So all it can do is do packet routing.

That's exactly what it does in the document above.

> But, real-world browsers don't do that, they pretend to be the only
> peer, and that's where the trouble starts.
>
>
>
> iang

Anders

[helpcrypto helpcrypto]

> My scenario is a billion+ community who haven't a clue what a CSP
> is and never will.  They may not even know what a certificate is!
>
> A CSP-solution doesn't give the issuer any information about where and
> how a key was generated.  The same goes for NSS, JCE, and PKCS #11.

Developer *can* know where keys were generated, cause keys are
generated for an specific CSP.
In other words: I (as a developer) select my CSP (which i know it maps
to a card) and generate keys -> keys are in the card.
Anyhow, this is technical discussion, and thats is what i want to avoid.

> See section 9.5 of:
> http://forja.cenatic.es/docman/view.php/160/684/cwa14890-01-2004-Mar.pdf

I know what SM messages are. I didnt understand "container
attestation". (As you already know, its my lack of english :P)

> http://openkeystore.googlecode.com/svn/trunk/resources/docs/Efficient-Provisioning-of-Complex-Structures-Over-Unsecured-Channels.pdf

Isnt that the same slides you already gave me?

> As can be seen from the documents, Secure Messaging isn't something you could bring up on a typical cocktail party :-) :-)

What kind of bloody insane naughty and lusty parties you go?
(Can i go with you?)

> If it works like "CertEnroll" or "SConnect" it is indeed an extremely
> bad idea because it exposes the card to accesses by untrusted parties.

So, a webpage should not be able to query smartcard (and get public
key from a card).
Cant we control that with a "this site is requesting smartcard access:
allow/deny?"

> Almost.  I started years ago with a protocol and later realized that

> secure messaging must be a part of that.  However, given the weirdness

> of smart cards, I found that you would also need a carefully matching
> container in order to ever get it supported inside a standard browser.

I thinks this is another story. Probably more correct or with a higher
knowledge, but "creating another standard" is not what im discussing
here.

As i asked you before, please, try to answer me this question (this
will help me undestand the problem):

I want to detect when the card is inserted, to be able to request a
cert (generate keys) inside the card (only).
Is "want i want" a bad idea? (you can always show an alert to
allow/deny web page card access)
How could we do it? (i think pkcs#11 its a simple/clear/well-known way
of doing it)

[helpcrypto helpcrypto]

> (to me, that question makes no sense.  users can't talk to smart cards.
>  Only smart card readers and programs can.  So what smart card reader and
> what program is doing this?  A dumb smart card reader and a browser,
> following Javascript instructions from a website?  That'd be game over...)

Why a website "cant" use javascript to communicate with the card?
A signed applet, for example, can read your hard drive
contents/execute, but only if you accept to do so.
Why cant we just show an allow/deny warning when trying to use a
pkcs#11 interface?


At least i hope you understand what im asking for. You can think its a
good or bad idea, but i hope you understand "my needs".

Again, the main basic core question is:
I need to do control an smartcard from web. Is that a logical a
request? (No matter what protocol or system do we use...its reasonable
to request that)

[ianG]

On 19/04/12 17:21 PM, helpcrypto helpcrypto wrote:
>> (to me, that question makes no sense. users can't talk to smart cards.
>> Only smart card readers and programs can. So what smart card reader and
>> what program is doing this? A dumb smart card reader and a browser,
>> following Javascript instructions from a website? That'd be game over...)
>
> Why a website "cant" use javascript to communicate with the card?

I can see where this difficulty is, I've worked on smart cards and it is
... perverse. I'll see if I can explain it. As an aside I have no idea
what the NSS people think, I'm not speaking for them, and they don't
typically like what I say :) Apologies out of the way, onwards!



No, javascript or any other random agent cannot talk to the card ...
just willy nilly. The logic goes like this:

The architect cared enough about the business and its risks to go for a
very expensive security option - a smartcard. This design placed
important secrets into a trusted platform which would not reveal or
misuse them, and the only reason to use such an expensive and awkward
form factor is that the architect really really cared about the secrets.

Now, *if you are serious about the security model*, then you will have
to do all the work to make the entire platform suite up to the same
level of security. (Otherwise you are not serious.)

This means that you need to ensure that whoever gets the smart card to
do important things has to be also /at the same level of security/.
That is, a peer. There are several ways to do this, but let's look at
the most simple for explanation: by being the same, in other words, by
being a smart card.

Good smart card security models will have smart cards talking to smart
cards. To do that, they need some concept of communications, which is
what SMs are (I'm guesssing here). (There are other ways, but as I say,
this is for explanation.)

So, your issue here is how do you prove that your javascript website is
a peer to the card? Well, it must have a smart card ... which
communicates via SMs ... which changes the nature of the application
tremendously ...

and as far as I know, that's not available in Firefox. Therefore we are
left at some sort of compromise. The compromise is probably something
like Firefox having a very tight rein on what can be done ... and in
practice this is strictly to handle things it knows about. e.g., client
certs to help setup SSL sessions and decrypt mails / encrypt mails.

*Nothing else* because otherwise Firefox is opening itself up to
breaches, it thinks. So the compromise here is that Firefox is saying
that it is the peer, and no other agent can be part of that. Including
plugins (?) websites and the like.

> A signed applet, for example, can read your hard drive
> contents/execute, but only if you accept to do so.
> Why cant we just show an allow/deny warning when trying to use a
> pkcs#11 interface?

Sure. But, that's a different level of security. Disk drives and
signed applets are moderate-to-boring. Smart cards are several cuts
above that. Just as an example, a proper security model would never let
a user choose low level things out of its trusted platform. E.g., "pay
now" and "enter pin" are good user things, "read cert" is not.

> At least i hope you understand what im asking for. You can think its a
> good or bad idea, but i hope you understand "my needs".

Maybe. You want the smart card to authenticate itself to you? I think.

Have you thought about imposing client certs in Appache/httpd and
setting up an SSL connection? Then, in httpd, you can expose the
certificate and present it in program variables.

There was also some mention of document signing. Yeah, I think I
understand that application ... and I'd say you haven't got a lot of
hope there in getting the smart card open for that via Firefox. How
about a downloaded app?

> Again, the main basic core question is:
> I need to do control an smartcard from web. Is that a logical a
> request? (No matter what protocol or system do we use...its reasonable
> to request that)

See my emphasis above. If you really care about the security model, you
have to have something of equal security speak to the smart card and
communicate at its level.

In the alternate, you don't care enough. So you don't need smart cards
at all. You're better off using software techniques.

(It would be nice to use software client certificates, but I think you
can now see that the above security implications and especially the
compromises left software client certs in an equivalently strangled
position - they were treated as crippled smart cards rather than as
security-balanced tools, and the result was that they were broken on two
counts not just one.)



iang

[Anders Rundgren]

On 2012-04-19 09:21, helpcrypto helpcrypto wrote:
>> (to me, that question makes no sense. users can't talk to smart cards.
>> Only smart card readers and programs can. So what smart card reader and
>> what program is doing this? A dumb smart card reader and a browser,
>> following Javascript instructions from a website? That'd be game over...)
>
> Why a website "cant" use javascript to communicate with the card?

A number of banks came up with the wonderful idea adding a citizen ID
application to their already shipping EMV (payment) card.

What this meant was that any merchant could read your citizen ID certificate
(=national ID) without your knowledge. Naturally this scheme was endorsed
by the government and their consultants.

I'm by *no means* a privacy advocate but this is way below what I consider
a useful solution. My criticism of this idea made me quite unpopular but
it seems that they actually never put it in production :-|

Anyway, this was another way of expressing a core problem with "direct access".
I do not think that "clever" GUIs can do much here either. Then there are
security-related stuff such as PIN spoofing and associated credential misuse
that I makes me pretty uncomfortable with the whole idea.

My "solution" to this is to treat all PKI-using applications as complete
applications running in trusted code. W3C tries to do something different,
we'll see how that pans out...

Anders

[helpcrypto helpcrypto]

> I can see where this difficulty is, I've worked on smart cards and it is ...
> perverse.  I'll see if I can explain it.  As an aside I have no idea what
> the NSS people think, I'm not speaking for them, and they don't typically
> like what I say :)  Apologies out of the way, onwards!

This sounds promising!

> Good smart card security models will have smart cards talking to smart
> cards.  To do that, they need some concept of communications, which is what
> SMs are (I'm guesssing here).  (There are other ways, but as I say, this is
> for explanation.)

When communicating to an smartcard, you need to send "commands".
"hello?"--->
<---hello im card
what mechanisms you provide?--->
<---i do RSA 1024 key gen, sign and en/decrypt
do you have RSA keys?--->
<---yes, i have one

SM just let you wrap this communication, like SSL, to be unreadable
(+avoid man in the middle...and so)
So, dont think in card communicating between them. This could be, but
that is other part of story.

> Sure.  But, that's a different level of security.  Disk drives and signed
> applets are moderate-to-boring.  Smart cards are several cuts above that.
>  Just as an example, a proper security model would never let a user choose
> low level things out of its trusted platform.  E.g., "pay now" and "enter
> pin" are good user things, "read cert" is not.

This simplest level of security is what im talking about...forget the
SM, forget other higher/complex things.
This page is trying to get access to your smartcard, Do you allow this?
(if you have an smartcard inserted on a reader, you "know" what an smartcard is)

> Maybe.  You want the smart card to authenticate itself to you?  I think.

OMG...i really suck in english, isnt it?

> There was also some mention of document signing.  Yeah, I think I understand
> that application ... and I'd say you haven't got a lot of hope there in
> getting the smart card open for that via Firefox.  How about a downloaded
> app?

Web. Im looking for a web solution (better than Java, or being
compatible with Java, at least)


Now i start thinking i should hire a professional translator...

[helpcrypto helpcrypto]

> My "solution" to this is to treat all PKI-using applications as complete
> applications running in trusted code.  W3C tries to do something different,
> we'll see how that pans out...

Ok Anders, but you are -again- talking much about your protocol, not
answering my question (or at least, i didnt get it as clear as water).
I think, this must be a communication problem between my spanish and
yours swedish (?). I really sorry for that.

Im talking about something much more simpler: "Detect a card insertion
and be sure the card is doing the operation i requested".

For example:
Within a browser, i click on "dear card, please, RSA sign this data" button.

IIUC, you say "that should not be done" or "that is not good for ~ reasons".
And that is want to know.

Why, if i request a certificate using a webpage (=generate keypair), i
cant control if the operation is performed within the card (not in
softokn)?
(Using latest build, i can do that operation, but i cant control where
is done...)

Actually, if i access an untrusted SSL site, i see a warning "you are
about to enter on an untrested site..."
Why i could not see "this page wants to use the smartcard..." warning?

Maybe, this discussion should be on private to avoid spamming
dev-tech-crypto list...?

[Anders Rundgren]

On 2012-04-19 16:41, helpcrypto helpcrypto wrote:
>> My "solution" to this is to treat all PKI-using applications as complete
>> applications running in trusted code. W3C tries to do something different,
>> we'll see how that pans out...
>
> Ok Anders, but you are -again- talking much about your protocol,

Dear HelpCrypto, I'm not pushing my protocol. I just don't think
that web-pages should be able to directly address *any* device
but the screen. If you take PKCS #11 it has a lot of methods and
I haven't a clue how to warn/alert the user when a method is called
in a way that makes sense.

Since you typically need a bunch of calls in order to do something
"pkcs11-ish" you would annoy the user with tons of warning dialogs.

If Mozilla thinks this is viable solution I think it is (about) time to speak up!

BTW, I don't think your English is that bad :-) I'm no pro either :-)

Anders

[helpcrypto helpcrypto]

> Dear HelpCrypto, I'm not pushing my protocol.  I just don't think
> that web-pages should be able to directly address *any* device
> but the screen.

If that were true, many things (like JSS) should dissapear from MDN.
Dont missunderstand. Im not complainning you or your protocol.

> If you take PKCS #11 it has a lot of methods and
> I haven't a clue how to warn/alert the user when a method is called
> in a way that makes sense.

PKCS#11 standard is very clear on that ;)

> Since you typically need a bunch of calls in order to do something
> "pkcs11-ish" you would annoy the user with tons of warning dialogs.

False, just a warning to confirm the website can use the smartcard,
and PIN/Password when needed.

> If Mozilla thinks this is viable solution I think it is (about) time to speak up!

Im trying to do so.

> BTW, I don't think your English is that bad :-)  I'm no pro either :-)

Good to hear, ill count this as private lessons ;)

PS: you havent still answered the question.

[ianG]

On 20/04/12 00:41 AM, helpcrypto helpcrypto wrote:
>> My "solution" to this is to treat all PKI-using applications as complete
>> applications running in trusted code. W3C tries to do something different,
>> we'll see how that pans out...
>

> Ok Anders, but you are -again- talking much about your protocol, not

> answering my question (or at least, i didnt get it as clear as water).
> I think, this must be a communication problem between my spanish and
> yours swedish (?). I really sorry for that.

No, don't be boring. No tiene nada que ver con el idioma, tu ingles es
ma'o'menos perfecto :P

The problem is that Anders is steeped in the theoretical and
intellectual models of the area, and has internalised more than we can
imagine. He leaps quickly from area to area.

He's saying the same thing as me - but using his formal language. You
will find the same problem between any set of cross-domain geeks talking
two domain languages over a common natural language.

Where he says "trusted code" I say "peer to peer". It's the same thing
viewed from a different angle.

> Im talking about something much more simpler: "Detect a card insertion
> and be sure the card is doing the operation i requested".

My guess is: that sort of info likely won't ever be exposed by Mozilla
to websites because (developers think) it can be abused as part of an
attack. The way Firefox is constructed in security terms is that less
information is better, even at the risk of unreliability and system fail.

Try debugging basic SSL protocol failures; both sides send
incomprehensible numbers to each other, and the browser reports these to
the user with smugness. "The server is misconfigured because it said
12345 which means goobledygook from the fligimidigget."

You're asking for something that appears to you reasonable - as an app
developer. But it is a long way away from where the software mindset is
- for the browser developer. Now you're talking in a foreign language
to them :)

> For example:
> Within a browser, i click on "dear card, please, RSA sign this data" button.

I doubt that would pass the security review at Mozilla. That's what I
thought you were trying to do. It's a non-starter.

The webserver that instructs the browser isn't a peer. So, basically
you are saying that any webserver or any browser can instruct the card
to sign anything.

(The browser isn't a peer to a smart card, but it pretends to be. And
it is so unconfident of its work that it jealously guards everything to
itself, even at the risk of failure. Given all that, why bother with a
smart card? These are self-fulfilling prophecies...)

> IIUC, you say "that should not be done" or "that is not good for ~ reasons".
> And that is want to know.

The reason is you cannot control other agents owned by attackers doing
the same thing. So your signature is worthless, because as soon as
someone adds value to your signature, others will come and steal the
value away.

Hypothetically, at a minimum, I'd be looking for the request to come
signed by some other peer RSA key. (partial answer only... but it is
meaningful to the developer?)

Which means that the smart card has to mediate the request, or there
needs to be some standard approach to this from PKIX or somewhere.
Which there isn't, as far as I know.

> Why, if i request a certificate using a webpage (=generate keypair), i
> cant control if the operation is performed within the card (not in
> softokn)?

There is "generate keypair" and there is "request a certificate". These
are entirely different.

1. The "generate keypair" thing (keygen?) is only for the Software
Security Device as an assist in the process of turning it into a
CA-signed cert.

It is *only* for creating a keypair and not for creating certificates
because otherwise it would go against the CA business model - all certs
must be signed by CAs - and that is sacrosanct in Mozilla security
model. In short, you can request a keypair, but you must then take it
out as a CSR and get it CA-signed.

It can't be for the smart card because that would mean there was a
standard provisioning service (some words used to describe getting the
right certs onto the smart card securely) available in the standards
world. There isn't. As far as I know. Ask Anders, he's authoritive on
this.

I know I'm not telling you *why it is like this* ... the first part
necessary is to understand how the world is.



2. When you request a (completed) certificate, it is the user's choice
where it comes from. It is considered part of the user's rights and
freedoms. (Or so, Mozilla would view it.)

If you could specify which certificate, you could also map out the
user's identity framework, and this would be a breach of privacy.
(Indeed, there are filed bugs because servers can silently request certs
from users of Firefox, if a certain button is clicked in them which is
recommended to be clicked all the time otherwise the users gets spammed
by popups :( )

What you can do is examine the cert supplied for various EKUs, OIDs, and
for the CA signing chain, etc. That's because in PKI theory the
certificate carries a /claim/ as signed by a /CA/ and the claims should
be substitutable on their wordings. You are meant to rely on the claim,
in PKI theory. So asking for a particular security model is the wrong
question, you should be examining the certificate presented at the
user's choice for a /claim/ signed by a CA that you trust to say that
"this certificate is certified by the CA as being duly protected to
smart card standards" or whatever other claim you are looking for.

E.g., Qualified Certificates will try and do this.

That's according to PKI theory. I'm not offering any opinions about
that :) Just trying to explain the world as it is.

> (Using latest build, i can do that operation, but i cant control where
> is done...)

Here, you mean the keygen operation? I think it has to be the Software
Security Device. aka, the soft-token ?

> Actually, if i access an untrusted SSL site, i see a warning "you are
> about to enter on an untrested site..."
> Why i could not see "this page wants to use the smartcard..." warning?

Some UI tests have shown 99% of those warnings to be ignored. Some
optimistic tests have shown only 60% are ignored... Some active
teaching experiences have shown they can get it down to 30% with
training, but the test repeated after 3 months shows return to bad habits :)

Is your application so valueless that you can cope with that? When
using smart card systems, you'll notice there are no warnings... because
the smart card designers at least know that if they rely on warnings,
it's game-over.

The economic problem of smart cards is that they cost a lot of money.
So they can only be used to ... protect a lot of money. So they cannot
use the "cheap-no-value-ignorable" tricks that browsers use like
spamming the user with 4 clicks to get to her cert. That's because, if
the trick doesn't work, the user loses money. If the user loses money,
she gets very upset, and the multiplier effect is such that the entire
ecosystem stops within short order.

Mind you, we don't know how valuable or valueless your application is.
Perhaps you could tell us what the key pair or signature is used for?

> Maybe, this discussion should be on private to avoid spamming
> dev-tech-crypto list...?

Well, others will chime in and say their bored if they're bored :)



iang

[ianG]

On 20/04/12 00:28 AM, helpcrypto helpcrypto wrote:
>> I can see where this difficulty is, I've worked on smart cards and it is ...
>> perverse. I'll see if I can explain it. As an aside I have no idea what
>> the NSS people think, I'm not speaking for them, and they don't typically
>> like what I say :) Apologies out of the way, onwards!
>
> This sounds promising!
>
>> Good smart card security models will have smart cards talking to smart
>> cards. To do that, they need some concept of communications, which is what
>> SMs are (I'm guesssing here). (There are other ways, but as I say, this is
>> for explanation.)
>
> When communicating to an smartcard, you need to send "commands".
> "hello?"--->
> <---hello im card
> what mechanisms you provide?--->
> <---i do RSA 1024 key gen, sign and en/decrypt
> do you have RSA keys?--->
> <---yes, i have one
>
> SM just let you wrap this communication, like SSL, to be unreadable
> (+avoid man in the middle...and so)
> So, dont think in card communicating between them. This could be, but
> that is other part of story.

The point is at the upper layers, the other party has to be trusted.

SMs ensure that the smart-card's counterparty is trusted.

SSL might offer that too. It does in principle, in marketing. But the
details matter too much for it to be reliable. For easy example, smart
cards typically don't do SSL. So there is some other agent between you
and the smart card that is "promising" to tell the smart card that you
are the trusted party.

That's generally not acceptable in the smart card world, because of the
economic logic I outlined - you chose a high security method, you have
to impose that same security over every step. End-to-end is not
decomposable into small components just because someone sold you a cheap
SSL connection with a bunch of marketing buzzwords.

>> Sure. But, that's a different level of security. Disk drives and signed
>> applets are moderate-to-boring. Smart cards are several cuts above that.
>> Just as an example, a proper security model would never let a user choose
>> low level things out of its trusted platform. E.g., "pay now" and "enter
>> pin" are good user things, "read cert" is not.
>
> This simplest level of security is what im talking about...forget the
> SM, forget other higher/complex things.
> This page is trying to get access to your smartcard, Do you allow this?

No.

It ain't me :) It's Firefox. But the answer's the same - NO.

> (if you have an smartcard inserted on a reader, you "know" what an smartcard is)

No. The smart card reader *might know what a smart card is*. But it
cannot easily provide any guarantee of that. Specifically it cannot
provide any guarantee that it is not really just a USB cable to another
computer with a soft token on it.

(How does Firefox get around that failure? Well, once we've accepted
the word at the bottom, it should be clearer ...)

>> Maybe. You want the smart card to authenticate itself to you? I think.
>
> OMG...i really suck in english, isnt it?

No, not at all. It's just that you are leaping from prior assumption
"smart card is insisted on because it is high security" all the way to
your development priority "gotta get the code working regardless of the
security implications" without pause.

That involves some suckiness in wording, in any language, coz you are
dropping a promise made earlier.

>> There was also some mention of document signing. Yeah, I think I understand
>> that application ... and I'd say you haven't got a lot of hope there in
>> getting the smart card open for that via Firefox. How about a downloaded
>> app?
>
> Web. Im looking for a web solution (better than Java, or being
> compatible with Java, at least)
>
>
> Now i start thinking i should hire a professional translator...

No, you need a secured browser. You need an entire team working in the
browser to build a proper security model, and expose that to a security
API on the website. Then you need to get that through PKIX :D and wait
over a decade before the others pick it up.

You are assuming that just because the browser happens to talk to a
smart card, the browser's security model is what you think it is. No
such luck.

One word: compromise.

That word describes Firefox's smart card model, as well as your own
position ;) It also describes why others (banks, EU, etc) have not
seemed to get this working.



iang

[ianG]

On 20/04/12 01:06 AM, helpcrypto helpcrypto wrote:

>> Since you typically need a bunch of calls in order to do something
>> "pkcs11-ish" you would annoy the user with tons of warning dialogs.
>
> False, just a warning to confirm the website can use the smartcard,
> and PIN/Password when needed.

Yes, technically that can be done. In code. But, security-model wise,
it cannot be done.

Think of phishing. We know that the average userbase is phished quite
successfully. Losses seem to run to many millions per year. Some
estimates ran to a billion a year, but it seems more likely to be around
100m a year.

Phishing is directly about the browser's warnings and interfaces
protecting the user from doing the "wrong thing" whatever that is.

And it failed. The browser explicitly directly positively failed to
protect the user from, and we know that because the security model it
has is explicitly directly positively targetted to doing exactly that -
stop someone bad pretend to be someone good.

So, we can reasonably claim with a high degree of certainty - because we
have all the phishing history & losses to rely on - that when your
preferred design of a warning is put out there, the user will be phishable.

This is a pretty reliable statement. If you want to challenge the
above, you've kinda got to imagine that you can do better than Mozilla
or that phishing didn't happen or thieves are allergic to smart cards or ?

So, do you accept that? Warning means Phishing.

If you do ... then we can ask several questions.

How much value are you protecting? Are smart cards the right tool?

And, is Mozilla interested in exposing all smart cards to phishing?

Difficult questions :)



iang

[helpcrypto helpcrypto]

After reading your three mails, i have only one thing to say: Clear as water.

Thank a lot for your patience and effort on explaining this for
short-minded like me.
Thanks a lot, REALLY, for your long, detailed and clear answer.
Of course, thanks a lot to Anders (which also suffered me) and others,
for the patience you are showing.

Now, a few comments to some of yours and some questions at the end.

> Here, you mean the keygen operation? I think it has to be the Software Security Device. aka, the soft-token ?

When an smartcard is present, and a request to generate a keypair is
made, Mozilla shows a dialog to select the cryptographic device where
the keys are going to be. If im developing a page to "request a
certificate" on the smartcard, i (as a developer) CANT control if the
user selects the card or softokn.

So, if the user doesnt read the BIG warning that i show ("you must
select the CARD!!!"), and never does, the keys are generated on
softokn and that ends in many problems. Starting with the user
thinking the cert is on the smartcard, where is not. Our users know
what "the card" is.

> Some UI tests have shown 99% of those warnings to be ignored. Some
> optimistic tests have shown only 60% are ignored... Some active teaching
> experiences have shown they can get it down to 30% with training, but the
> test repeated after 3 months shows return to bad habits :)

dont tell me.
-------------------->you must select the CARD!!!

> Is your application so valueless that you can cope with that? When using
> smart card systems, you'll notice there are no warnings... because the smart
> card designers at least know that if they rely on warnings, it's game-over.

This proves you havent used spanish DNIe.
Designers decide that, as a warning can be ignored, make sure user
dont ignore the warnings.
So DNIe show 2384729847239874923794 warnings, and i ignore them all.

> Mind you, we don't know how valuable or valueless your application is.
> Perhaps you could tell us what the key pair or signature is used for?

company users need to sign documents (xml/pdf...) or mail
we use FNMT (some guy could be killed for that) certs
we have an smartcard where we put the cert in.
we want users to be able to sign data (webforms or documents) using
web [Actually using Java]
we want users to be able to request certs 'directly' on smartcard
(from a website)

Do you need more details?

I understand "this is a trusted site" is FAR AWAY from "this is a
trusted site that can read my hard drive/execute commands".
Signed applets, at the other hand, have full access, and can access to
the smartcard.
If there are no better options at the moment, shouldnt we
(mozilla/firefox) suport them properly?

[Anders Rundgren]

On 2012-04-20 10:34, helpcrypto helpcrypto wrote:
> After reading your three mails, i have only one thing to say: Clear as water.
>
> Thank a lot for your patience and effort on explaining this for
> short-minded like me.
> Thanks a lot, REALLY, for your long, detailed and clear answer.
> Of course, thanks a lot to Anders (which also suffered me) and others,
> for the patience you are showing.

Thanx!!!

>
> Now, a few comments to some of yours and some questions at the end.
>
>
>> Here, you mean the keygen operation? I think it has to be the Software Security Device. aka, the soft-token ?
>
> When an smartcard is present, and a request to generate a keypair is
> made, Mozilla shows a dialog to select the cryptographic device where
> the keys are going to be. If im developing a page to "request a
> certificate" on the smartcard, i (as a developer) CANT control if the
> user selects the card or softokn.

Helpcrypto, a possible *long-term* solution to this is that the requester
indicates such preferences. So if the requester says "external card"
(for example) the dialog would not need the user to select. If there
is no card present, it would ask the user to insert a suitable card.
This is at least how KeyGen2 works.

This is of course not of my business but I personally do not
see JSS neither as the solution for "now" or "the future".

I think these guys have do a huge work with signature Applets:

http://www.openoces.org

Anders

[Martin Paljak]

Hello,

On Fri, Apr 20, 2012 at 13:53, Anders Rundgren
<anders....@telia.com> wrote:

> I think these guys have do a huge work with signature Applets:
>
> http://www.openoces.org

I don't know about practical differences, as I've not tested either
applet in real life applications, but there's another interesting
applet out there (which support quite an impressive amount of cards):

http://egovlabs.gv.at/projects/mocca/

Martin

[helpcrypto helpcrypto]

> Helpcrypto, a possible *long-term* solution to this is that the requester
> indicates such preferences. So if the requester says "external card"
> (for example) the dialog would not need the user to select. If there
> is no card present, it would ask the user to insert a suitable card.
> This is at least how KeyGen2 works.

I consider this a step forward. Not the solution, but actually
improves current situation.

> This is of course not of my business but I personally do not
> see JSS neither as the solution for "now" or "the future".

And what about applets without JSS, using Secmod [1] or the sunpkcs11
[2] provider?

> http://www.openoces.org
> http://egovlabs.gv.at/projects/mocca/
Going to look, but we already have an applet using JSS (and im now
moving to non-JSS)

[1] http://www.docjar.com/docs/api/sun/security/pkcs11/Secmod.html
[2] http://www.docjar.com/docs/api/sun/security/pkcs11/SunPKCS11.html

[helpcrypto helpcrypto]

> And what about applets without JSS, using Secmod [1] or the sunpkcs11
> [2] provider?
>

> [1] http://www.docjar.com/docs/api/sun/security/pkcs11/Secmod.html
> [2] http://www.docjar.com/docs/api/sun/security/pkcs11/SunPKCS11.html

Any comments?