Re: Prevent "proxyfying" PKCS#11

[helpcrypto helpcrypto]

Julien: you and me have "at the end" the same problem.

Java Web applets are passing away and we are looking for alternatives.


If you are just talking about "scanning", there 3 options AFAIK to do that:
 - From web invoke 127.0.0.1:port application(service) which listens on
port X and do all the job with the twain scanner
 - From the Web invoke myscan:// application protocol (look for registering
protocols on system at Google) and although you'll get a warning dialog,
the application could twain-scan and send result to a server
 - Forget about twain. The trust-chain of scanning is broken, but you can
scan over network and the upload JPG to your webform :P


If you are somehow worried about security (ie: "certified scanning") then
we are both "on the same problem".

Developing your own twain driver for network scanners will be -probably-
much more expensive that using xane or buying a USB new one.
You still have the scanner-web issue, but that can be solved easily (using
option #1+random number/token)
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Prevent "proxyfying" PKCS#11

[Julien Pierre]

Erwann,

On 9/28/2015 12:21, Erwann Abalea wrote:
I mistaken with Firefox, which still supports NPAPI, and all Java 
applets are in "click-to-play" mode. 

OK, great !

I certainly need Java in the browser, for other reasons (running a
scanner applet to use with my bank).

Then you can't use an Android or iOS device or the new MS browser for this 
activity. Not cool.
It's quite fine with me - I don't expect my scanner to work with my cell 
phone.


On my phone, I have the option to use a mobile check deposit app 
instead. But I find this much less reliable than using a scanner.
Lighting is often bad, there are shadows, focus issues, and the angle 
makes them look strange, etc.

It's much more cumbersome to do this with a smartphone than with a scanner.

While the scanner is networked, there are no Twain drivers for the 
scanner for Android, only for PC and Mac.
There is a separate scanning app that works on the phone, but that 
doesn't interact with the browser.
Java and the browser plug-in are needed to tie the scanner to the 
browser and server.


Julien

--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Prevent "proxyfying" PKCS#11

[Julien Pierre]

Yes, I think you are right, and we have digressed.

On 9/28/2015 17:30, Robert Relyea wrote:

On 09/25/2015 09:13 AM, Erwann Abalea wrote:
Le vendredi 25 septembre 2015 14:39:04 UTC+2, helpcrypto helpcrypto a 
écrit :
On Fri, Sep 25, 2015 at 11:52 AM, Erwann Abalea  
wrote:

[...]

Although it won't solve my problem, this will make possible to kill
signature applets forever, which indeed it's my real objective.
This objective will soon be reached. Java isn't supported anymore in 
Chrome 45 and is supposedly to be deprecated in Firefox soon, and 
ActiveX (whence Java also) won't be supported in Edge.
I thought helpcrypto was suggesting using a javacard applet, not java 
that runs on the client. Of course to install a javacard applet you 
need the card keys, which I believe he said he didn't have.


bob






--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Prevent "proxyfying" PKCS#11

[Julien Pierre]

On 9/28/2015 01:50, helpcrypto helpcrypto wrote:

On Sat, Sep 26, 2015 at 1:17 AM, Julien Pierre 
wrote:


Erwann,

What are the replacement plug-in API mechanisms following the deprecation
of NPAPI ?


Oracle porting to PPAPI? (Perhaps you could give us some privileged
information about this)
I was under the impression that only Google chrome is supporting PPAPI, 
but not Firefox.
Anyway, I do not work on Java and have no information about porting the 
browser plug-in to a new API.


Julien

--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Prevent "proxyfying" PKCS#11

[Julien Pierre]

Personally, I don't think authenticating the scanner is an issue. I can 
see the document physically being scanned in the scanner.

And I can see the resulting image in the java applet on my screen.
If the document that appears is not what I scanned, I would simply not 
submit it. I'm not worried about authenticating my scanner.


My bank feels differently, however.  They won't allow users to just 
upload any random JPG file - it has to be input directly from a scanner, 
or through a mobile phone's camera. It probably doesn't make that much 
sense - any human being who can upload a fake check JPG could probably 
also print it, and then scan it or take a picture of it with the mobile 
phone.


This security measure really only prevents an automated program from 
generating and submitting the fake check JPG, until they can fake a 
phone camera or a Twain scanner in software, which is a bit more involved.


Julien

On 9/29/2015 01:23, helpcrypto helpcrypto wrote:

Julien: you and me have "at the end" the same problem.

Java Web applets are passing away and we are looking for alternatives.


If you are just talking about "scanning", there 3 options AFAIK to do that:
  - From web invoke 127.0.0.1:port application(service) which listens on
port X and do all the job with the twain scanner
  - From the Web invoke myscan:// application protocol (look for registering
protocols on system at Google) and although you'll get a warning dialog,
the application could twain-scan and send result to a server
  - Forget about twain. The trust-chain of scanning is broken, but you can
scan over network and the upload JPG to your webform :P


If you are somehow worried about security (ie: "certified scanning") then
we are both "on the same problem".

Developing your own twain driver for network scanners will be -probably-
much more expensive that using xane or buying a USB new one.
You still have the scanner-web issue, but that can be solved easily (using
option #1+random number/token)


--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Prevent "proxyfying" PKCS#11

[Erwann Abalea]

(This is off-topic, no further answer from me on this subject)

Bonsoir,

Le samedi 26 septembre 2015 01:17:49 UTC+2, Julien Pierre a écrit :
> What are the replacement plug-in API mechanisms following the 
> deprecation of NPAPI ?

PPAPI.

> Can't they be used to write another Java plug-in ?

I don't know. Oracle doesn't seem to move to PPAPI, and pushes for other 
browsers.
I mistaken with Firefox, which still supports NPAPI, and all Java applets are 
in "click-to-play" mode.

> I certainly need Java in the browser, for other reasons (running a 
> scanner applet to use with my bank).

Then you can't use an Android or iOS device or the new MS browser for this 
activity. Not cool.
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: [Opensc-devel] Prevent "proxyfying" PKCS#11

[helpcrypto helpcrypto]

On Fri, Sep 25, 2015 at 3:47 PM, Ludovic Rousseau <
ludovic.rouss...@gmail.com> wrote:

> Hello,
>
> 2015-09-25 14:45 GMT+02:00 helpcrypto helpcrypto :
> > But we still have the issue with the data sent from server. eg: server
> sent
> > "sign these 10 documents" to our opensource Java local application which
> > asks PKCS#11 to do it.
> > Anyone could decompile, and inject an 11th doc on the request.
>
> Some cards can be configured so that the PIN have to be presented
> before _each_ signature.
> If the user knows he has 10 documents to sign and he is asked to enter
> his PIN 11 times then he should detect a problem.
>

Althouth that could solve "partially" the problem, it's not an intended
feature. Users complaint this being annoying, even if we cache the PIN and
just request yes/no to confirm.



> The user should verify after each signature that the document he
> wanted to sign is correctly signed. If not then he should suspect a
> problem. Maybe another document has been signed instead, or something
> went wrong.
>

As stated previusly, if our client application is open-source, anyone could
manipulate that and show whatever they want.



> If you do not use a pinpad the PIN is available somewhere in RAM and a
> rogue software could use it.
>
> > That's what we are trying to avoid and our opinion is actually: if the
> > computer is compromised, you can't do anything.
>
> Exact. If the computer is compromised you have NO idea of what it is
> doing.
>

Starting to get convinced...
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Prevent "proxyfying" PKCS#11

[helpcrypto helpcrypto]

On Sat, Sep 26, 2015 at 1:17 AM, Julien Pierre 
wrote:

> Erwann,
>
> What are the replacement plug-in API mechanisms following the deprecation
> of NPAPI ?
>

Oracle porting to PPAPI? (Perhaps you could give us some privileged
information about this)



> Can't they be used to write another Java plug-in ?
>
> I certainly need Java in the browser, for other reasons (running a scanner
> applet to use with my bank).
> Julien


We also use an applet for that, but it's another pal problem :P


On 9/25/2015 09:13, Erwann Abalea wrote:
>
>> Le vendredi 25 septembre 2015 14:39:04 UTC+2, helpcrypto helpcrypto a
>> écrit :
>>
>>> On Fri, Sep 25, 2015 at 11:52 AM, Erwann Abalea 
>>> wrote:
>>>
>> [...]
>>
>>> Although it won't solve my problem, this will make possible to kill
>>> signature applets forever, which indeed it's my real objective.
>>>
>> This objective will soon be reached. Java isn't supported anymore in
>> Chrome 45 and is supposedly to be deprecated in Firefox soon, and ActiveX
>> (whence Java also) won't be supported in Edge.
>>
>
Do you have any supporting reference for Java "killing" on Firefox? AFAIK,
"click-to-play" is the only thing they have adopted.
NPAPI and Active X aren't supported in Edge, but in IE11, also bundled in
Windows 10.


I have to quit this job before it's too late...
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Prevent "proxyfying" PKCS#11

[Robert Relyea]

On 09/25/2015 01:36 AM, helpcrypto helpcrypto wrote:

Hi all


I hope you can find a solution for my problem, cause I can't. (And perhaps
it's impossible)


Based on my knowledge of PKCS#11 standard, the spec is exposed to a MITM
attack that steals the PIN when an application invokes C_Login against a
PK#11 library.


While using CryptoAPI it's the system who shows the "PIN dialog" making it
harder to crack/extract the PIN, C_Login function receives the PIN in
plaintext, and "an evil software", like PKCS11SPY, could get access to it.

Sadly, using Pinpads is out of scope/beyond our possibilities.
While dialog pin prompts don't really help all that much (if the 
attacker has your machine, they can pop up their own dialogs, just 
because the PKCS #11 software enforces a login, doesn't mean that the 
cards do. At the bottom the application can always talk directly to the 
card).


If you want dialog pin prompts, you can always just use protected pin 
path tokens, but then your application will only work with protected pin 
path tokens.


If your machine is compromised to the point that the attacker can insert 
PKCS11SPY into your PKCS #11 chain, there's very little you can do.




Of course my app could check pkcs#11 library checksum and other mechanisms
to "ensure" it is the library and not a proxy, but if my application is
opensource (I'll love to), I'm fu*ked.


Open source doesn't make this any worse, your proprietary app can be 
changed to accept the new checksum, or skip the checksum step 
altogether. In order to proxy PKCS #11 this way you need to be able to 
install a PKCS #11 module that does the proxying.


Is there any way to "trust" in the client? Can the server know the exe
being executed is MY exe and an EVIL copy? (A private key embebed can also
be cracked!)


Short answer: No. Long answer: The best you can do is under certain 
conditions the server can know the authentication key is in a token, but 
only if the server is part of the infrastructure that issued the cert 
and key and performed the appropriate checks to verify the key is in the 
token (and only in the token).





Furthermore, our *lovely* card sends APDU for login in plainText, so anyone
could see "1234" easily. And we are not able to establish a secure channel
cause we lack the required keys.
Every card does that. The connection between the computer and the reader 
is considered 'secure'.


bob



Seems what I really need is something like a Javacard applet with an
embebed "server public key", a component certificate and a session keypair
for mutual authentication and cipher communications between server and
client, but we aren't able to load this applet on the Card.


You'd need your own protocol for this. Card management systems usually 
do this with their own protocol where the server talks to the card 
directly through a global platform secure channel. This only works 
because the server is part of the trusted base for the card management 
system (e.i. the server knows the keys that even the user doesn't know 
for his card). Even then, you don't know that the user saw want 
documents he thinks he's signing because in your scenario the client 
computer is fundamentally untrusted. In the case where the computer is 
untrusted you can't get any guarantees. That's why most protocols assume 
that the client is at least trusted by the user of the client.


So, to sum up it seems it won't be possible to do what I need: a server
asking to sign 10 documents and being sure only those are signed.

I understand this is Anders (& CO) argument about "smartcards were not
designed for Web"


In the other hand, do you think is possible to "extend" WebcryptoAPI to
generate/use keys to/from browser or system keystore?
IMHO, how it actually works, sucks.


Regards (and thanks)

PS: Never trust the client...that also sucks.





smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Prevent "proxyfying" PKCS#11

[Robert Relyea]

On 09/25/2015 09:13 AM, Erwann Abalea wrote:

Le vendredi 25 septembre 2015 14:39:04 UTC+2, helpcrypto helpcrypto a écrit :

On Fri, Sep 25, 2015 at 11:52 AM, Erwann Abalea  wrote:

[...]

Although it won't solve my problem, this will make possible to kill
signature applets forever, which indeed it's my real objective.

This objective will soon be reached. Java isn't supported anymore in Chrome 45 
and is supposedly to be deprecated in Firefox soon, and ActiveX (whence Java 
also) won't be supported in Edge.
I thought helpcrypto was suggesting using a javacard applet, not java 
that runs on the client. Of course to install a javacard applet you need 
the card keys, which I believe he said he didn't have.


bob




smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: [Opensc-devel] Prevent "proxyfying" PKCS#11

[Ludovic Rousseau]

Hello,

2015-09-25 14:45 GMT+02:00 helpcrypto helpcrypto :
> But we still have the issue with the data sent from server. eg: server sent
> "sign these 10 documents" to our opensource Java local application which
> asks PKCS#11 to do it.
> Anyone could decompile, and inject an 11th doc on the request.

Some cards can be configured so that the PIN have to be presented
before _each_ signature.
If the user knows he has 10 documents to sign and he is asked to enter
his PIN 11 times then he should detect a problem.

The user should verify after each signature that the document he
wanted to sign is correctly signed. If not then he should suspect a
problem. Maybe another document has been signed instead, or something
went wrong.

If you do not use a pinpad the PIN is available somewhere in RAM and a
rogue software could use it.

> That's what we are trying to avoid and our opinion is actually: if the
> computer is compromised, you can't do anything.

Exact. If the computer is compromised you have NO idea of what it is doing.

Bye

-- 
 Dr. Ludovic Rousseau
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: [Opensc-devel] Prevent "proxyfying" PKCS#11

[Dirk-Willem van Gulik]

On 25 Sep 2015, at 10:36, helpcrypto helpcrypto  wrote:

> I hope you can find a solution for my problem, cause I can't. (And perhaps 
> it's impossible)

> Based on my knowledge of PKCS#11 standard, the spec is exposed to a MITM 
> attack that steals the PIN when an application invokes C_Login against a 
> PK#11 library.
...
> Sadly, using Pinpads is out of scope/beyond our possibilities.

This won’t solve your problem directly - but may still be useful (especially as 
I am guessing that as you are CC-ing the Mozilla list - that you are concerned 
with browsers).

One way we got things this to pass munster was to carefully make a 
threatmap/actor analysies - and then meet the various compliance & infosec 
expectations was by 1) dispensing with the PIN and 2) having a `what you know’ 
as part of the interaction through the browser (only). 

As this concerned access to something which was only accessible through the 
browser - we essentially argued that if one where able to manipulate the local 
browser/keyboard/system to such an extent as to be able to capture the PIN near 
the PKCS library/driver  - one would almost most certainly be able to get `at’ 
whatever the chipcard & pin where protecting `in’ the browser.

Dw


-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: [Opensc-devel] Prevent "proxyfying" PKCS#11

[Andreas Schwier]

Hi,

you mention a common problem with PIN authentication and smart cards: To
keep the PIN protected on the path between the PIN entry and chip must
be protected.

There are two alternatives:

1. Establish a secure channel between the card and the PIN pad.
2. Replace PIN authentication with public key authentication

The first is what TR-03110 does with PACE: The PIN is never traversing
the path from PIN pad to the card.

Alternatively you could use a protocol like ChipAuthentication to create
the secure channel before PIN verification occurs.

For C_Login the alternative is to use CKF_PROTECTED_AUTHENTICATION_PATH
and have a PIN dialog in the PKCS#11 module.

The second option is not very common with cards, even though that has a
lot of potential for server based scenarios.

In the current SmartCard-HSM we support creating a secure channel using
ChipAuthentication and use that channel to submit the PIN. The secure
channel is based on a 3 tier PKI that is used during device production
to issue a device certificate for the ChipAuthentication public key.

In the upcoming 2.0 release of the SmartCard-HSM we support public key
authentication (PKA) as replacement for PIN. PKA can be used in
combination with an n-of-m threshold scheme, so it is specifically
suited for applications where access to keys must be shared between key
custodians.

> Furthermore, our *lovely* card sends APDU for login in plainText, so
anyone
> could see "1234" easily. And we are not able to establish a secure channel
> cause we lack the required keys.
> 
> 
> Seems what I really need is something like a Javacard applet with an
> embebed "server public key", a component certificate and a session keypair
> for mutual authentication and cipher communications between server and
> client, but we aren't able to load this applet on the Card.
That's what the SmartCard-HSM does. And this is the mechanism we use
with the PKI-as-a-Service Demo [1]. A client (OCF) that acts as a
reverse APDU proxy connects to the server. The server application talks
to the remote card just like it talks to a locally connected card. It
initially reads and validates the device certificate, establishes a
secure channel with ChipAuthentication and then perform operations with
the card.

In the demo case, the PIN is entered locally at the client, either in
pop-up or using a PIN pad reader. The PIN is then bound to the secure
channel and if the secure channel terminates, the PIN authentication is
reset.
> 
> So, to sum up it seems it won't be possible to do what I need: a server
> asking to sign 10 documents and being sure only those are signed.
That can be done. I even know a web based application that can
electronically sign document according to the strict German signature law.
> 
> I understand this is Anders (& CO) argument about "smartcards were not
> designed for Web"
Not all smart cards are equals ;-)
> 
> 
> In the other hand, do you think is possible to "extend" WebcryptoAPI to
> generate/use keys to/from browser or system keystore?
That is something I never understood. Why does WebcryptoAPI not support
PKCS#11 ? What's the hidden agenda with software keys in the browser ?
Is it because Google/NSA want to know the key ?
> IMHO, how it actually works, sucks.
FullAck.

Andreas

[1] http://demo.openscdp.org/paas.html
> 
> 
> Regards (and thanks)
> 
> PS: Never trust the client...that also sucks.
> 
> 
> 
> --
> 
> 
> 
> ___
> Opensc-devel mailing list
> opensc-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
> 


-- 

-CardContact Software & System Consulting
   |.##> <##.|   Andreas Schwier
   |#   #|   Schülerweg 38
   |#   #|   32429 Minden, Germany
   |'##> <##'|   Phone +49 571 56149
-http://www.cardcontact.de
 http://www.tscons.de
 http://www.openscdp.org
 http://www.smartcard-hsm.com

-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Prevent "proxyfying" PKCS#11

[Erwann Abalea]

Le vendredi 25 septembre 2015 14:39:04 UTC+2, helpcrypto helpcrypto a écrit :
> On Fri, Sep 25, 2015 at 11:52 AM, Erwann Abalea  wrote:
[...]
> Although it won't solve my problem, this will make possible to kill
> signature applets forever, which indeed it's my real objective.

This objective will soon be reached. Java isn't supported anymore in Chrome 45 
and is supposedly to be deprecated in Firefox soon, and ActiveX (whence Java 
also) won't be supported in Edge.
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Prevent "proxyfying" PKCS#11

[Julien Pierre]

Erwann,

What are the replacement plug-in API mechanisms following the 
deprecation of NPAPI ?

Can't they be used to write another Java plug-in ?

I certainly need Java in the browser, for other reasons (running a 
scanner applet to use with my bank).

Julien

On 9/25/2015 09:13, Erwann Abalea wrote:

Le vendredi 25 septembre 2015 14:39:04 UTC+2, helpcrypto helpcrypto a écrit :

On Fri, Sep 25, 2015 at 11:52 AM, Erwann Abalea  wrote:

[...]

Although it won't solve my problem, this will make possible to kill
signature applets forever, which indeed it's my real objective.

This objective will soon be reached. Java isn't supported anymore in Chrome 45 
and is supposedly to be deprecated in Firefox soon, and ActiveX (whence Java 
also) won't be supported in Edge.


--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Prevent "proxyfying" PKCS#11

[helpcrypto helpcrypto]

Hi all


I hope you can find a solution for my problem, cause I can't. (And perhaps
it's impossible)


Based on my knowledge of PKCS#11 standard, the spec is exposed to a MITM
attack that steals the PIN when an application invokes C_Login against a
PK#11 library.


While using CryptoAPI it's the system who shows the "PIN dialog" making it
harder to crack/extract the PIN, C_Login function receives the PIN in
plaintext, and "an evil software", like PKCS11SPY, could get access to it.

Sadly, using Pinpads is out of scope/beyond our possibilities.



Of course my app could check pkcs#11 library checksum and other mechanisms
to "ensure" it is the library and not a proxy, but if my application is
opensource (I'll love to), I'm fu*ked.

Is there any way to "trust" in the client? Can the server know the exe
being executed is MY exe and an EVIL copy? (A private key embebed can also
be cracked!)


Furthermore, our *lovely* card sends APDU for login in plainText, so anyone
could see "1234" easily. And we are not able to establish a secure channel
cause we lack the required keys.


Seems what I really need is something like a Javacard applet with an
embebed "server public key", a component certificate and a session keypair
for mutual authentication and cipher communications between server and
client, but we aren't able to load this applet on the Card.

So, to sum up it seems it won't be possible to do what I need: a server
asking to sign 10 documents and being sure only those are signed.

I understand this is Anders (& CO) argument about "smartcards were not
designed for Web"


In the other hand, do you think is possible to "extend" WebcryptoAPI to
generate/use keys to/from browser or system keystore?
IMHO, how it actually works, sucks.


Regards (and thanks)

PS: Never trust the client...that also sucks.
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Prevent "proxyfying" PKCS#11

[helpcrypto helpcrypto]

On Fri, Sep 25, 2015 at 11:52 AM, Erwann Abalea  wrote:

> Bonjour,
>
> Le vendredi 25 septembre 2015 10:36:53 UTC+2, helpcrypto helpcrypto a
> écrit :
> > I hope you can find a solution for my problem, cause I can't. (And
> perhaps
> > it's impossible)
> >
> > Based on my knowledge of PKCS#11 standard, the spec is exposed to a MITM
> > attack that steals the PIN when an application invokes C_Login against a
> > PK#11 library.
>
> If a call to C_GetTokenInfo() returns the flag
> CKF_PROTECTED_AUTHENTICATION_PATH, then there's no PIN code to be sent in
> calls to C_Login(), C_SetPin(), C_InitToken(), etc. And the real
> authentication is device/vendor specific.
>

Sadly it doesn't.
The CryptoAPI middleware shows a window, but the PKCS#11 requires a PIN.


>
> > Of course my app could check pkcs#11 library checksum and other
> mechanisms
> > to "ensure" it is the library and not a proxy, but if my application is
> > opensource (I'll love to), I'm fu*ked.
> >
> > Is there any way to "trust" in the client? Can the server know the exe
> > being executed is MY exe and an EVIL copy? (A private key embebed can
> also
> > be cracked!)
> >
> > Furthermore, our *lovely* card sends APDU for login in plainText, so
> anyone
> > could see "1234" easily. And we are not able to establish a secure
> channel
> > cause we lack the required keys.
>
> And if you had the required keys, they would also be susceptible to theft,
> just as your previous private key.
>

I could store the keys on the server, making the application a dumb
repeater of crypted messages, not using PKCS#11 API but sending APDU to
card.
Butthe provider (Gemalto) won't give the keys.(...wait a second, dind't
they were stolen? lol )



> > In the other hand, do you think is possible to "extend" WebcryptoAPI to
> > generate/use keys to/from browser or system keystore?
> > IMHO, how it actually works, sucks.
>
> Technically, it's possible. But it doesn't seem to be a shared goal.
> Anyway, this wouldn't solve your initial problem.
>

Although it won't solve my problem, this will make possible to kill
signature applets forever, which indeed it's my real objective.
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: [Opensc-devel] Prevent "proxyfying" PKCS#11

[helpcrypto helpcrypto]

On Fri, Sep 25, 2015 at 11:21 AM, Dirk-Willem van Gulik <
di...@webweaving.org> wrote:

> On 25 Sep 2015, at 10:36, helpcrypto helpcrypto 
> wrote:
>
> > I hope you can find a solution for my problem, cause I can't. (And
> perhaps it's impossible)
>
> > Based on my knowledge of PKCS#11 standard, the spec is exposed to a MITM
> attack that steals the PIN when an application invokes C_Login against a
> PK#11 library.
> ...
> > Sadly, using Pinpads is out of scope/beyond our possibilities.
>
> This won’t solve your problem directly - but may still be useful
> (especially as I am guessing that as you are CC-ing the Mozilla list - that
> you are concerned with browsers).
>
Indeed

One way we got things this to pass munster was to carefully make a
> threatmap/actor analysies - and then meet the various compliance & infosec
> expectations was by 1) dispensing with the PIN and 2) having a `what you
> know’ as part of the interaction through the browser (only).
>

Server-side signature won't be a problem, as security is left for the
browser, but we are using cards, so the PIN has to reach the card, where
the certificate is stored.



> As this concerned access to something which was only accessible through
> the browser - we essentially argued that if one where able to manipulate
> the local browser/keyboard/system to such an extent as to be able to
> capture the PIN near the PKCS library/driver  - one would almost most
> certainly be able to get `at’ whatever the chipcard & pin where protecting
> `in’ the browser.
>

We are actually at that point. Browser is displaying a random number (kind
of OTP) and application show it to let the user know the request is
"trusted".
But we still have the issue with the data sent from server. eg: server sent
"sign these 10 documents" to our opensource Java local application which
asks PKCS#11 to do it.
Anyone could decompile, and inject an 11th doc on the request.
That's what we are trying to avoid and our opinion is actually: if the
computer is compromised, you can't do anything.


Thanks for your answers
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: [Opensc-devel] Prevent "proxyfying" PKCS#11

[helpcrypto helpcrypto]

On Fri, Sep 25, 2015 at 11:15 AM, Andreas Schwier <
andreas.schwier...@cardcontact.de> wrote:

> Hi,
>
> you mention a common problem with PIN authentication and smart cards: To
> keep the PIN protected on the path between the PIN entry and chip must
> be protected.
>
> There are two alternatives:
>
> 1. Establish a secure channel between the card and the PIN pad.
>

If you are talking about 7816 SM, we can't, cause the provider doesn''t
give us the needed keys.



> 2. Replace PIN authentication with public key authentication
>
> The first is what TR-03110 does with PACE: The PIN is never traversing
> the path from PIN pad to the card.
>
> Alternatively you could use a protocol like ChipAuthentication to create
> the secure channel before PIN verification occurs.
>
> For C_Login the alternative is to use CKF_PROTECTED_AUTHENTICATION_PATH
> and have a PIN dialog in the PKCS#11 module.
>

Our card doesn't support that.
Also note that not only the PIN is exposed, but the requests for signature.
(I send 5 documents to be signed, evil application add 1 and the user
signed 6 without our knowledge)



> The second option is not very common with cards, even though that has a
> lot of potential for server based scenarios.
>
> In the current SmartCard-HSM we support creating a secure channel using
> ChipAuthentication and use that channel to submit the PIN. The secure
> channel is based on a 3 tier PKI that is used during device production
> to issue a device certificate for the ChipAuthentication public key.
>
> In the upcoming 2.0 release of the SmartCard-HSM we support public key
> authentication (PKA) as replacement for PIN. PKA can be used in
> combination with an n-of-m threshold scheme, so it is specifically
> suited for applications where access to keys must be shared between key
> custodians.
>

Sadly, our card is "closed" and we are not able to do anything...otherwise
i could load a Javacard applet to do what I need in a secure way.


> Furthermore, our *lovely* card sends APDU for login in plainText, so
> anyone
> > could see "1234" easily. And we are not able to establish a secure
> channel
> > cause we lack the required keys.
> >
> >
> > Seems what I really need is something like a Javacard applet with an
> > embebed "server public key", a component certificate and a session
> keypair
> > for mutual authentication and cipher communications between server and
> > client, but we aren't able to load this applet on the Card.
> That's what the SmartCard-HSM does. And this is the mechanism we use
> with the PKI-as-a-Service Demo [1]. A client (OCF) that acts as a
> reverse APDU proxy connects to the server. The server application talks
> to the remote card just like it talks to a locally connected card. It
> initially reads and validates the device certificate, establishes a
> secure channel with ChipAuthentication and then perform operations with
> the card.
>
> In the demo case, the PIN is entered locally at the client, either in
> pop-up or using a PIN pad reader. The PIN is then bound to the secure
> channel and if the secure channel terminates, the PIN authentication is
> reset.
>

Have to have an eye on [1]!

>
> > So, to sum up it seems it won't be possible to do what I need: a server
> > asking to sign 10 documents and being sure only those are signed.
> That can be done. I even know a web based application that can
> electronically sign document according to the strict German signature law.
> >
> > I understand this is Anders (& CO) argument about "smartcards were not
> > designed for Web"
> Not all smart cards are equals ;-)
> >
> >
> > In the other hand, do you think is possible to "extend" WebcryptoAPI to
> > generate/use keys to/from browser or system keystore?
> That is something I never understood. Why does WebcryptoAPI not support
> PKCS#11 ? What's the hidden agenda with software keys in the browser ?
> Is it because Google/NSA want to know the key ?
>
> IMHO, how it actually works, sucks.
> FullAck.
>
> Andreas
>
> [1] http://demo.openscdp.org/paas.html
>

I really have to read about this, but I don't know if our card will support
it.
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Prevent "proxyfying" PKCS#11

[Erwann Abalea]

Bonjour,

Le vendredi 25 septembre 2015 10:36:53 UTC+2, helpcrypto helpcrypto a écrit :
> I hope you can find a solution for my problem, cause I can't. (And perhaps
> it's impossible)
> 
> Based on my knowledge of PKCS#11 standard, the spec is exposed to a MITM
> attack that steals the PIN when an application invokes C_Login against a
> PK#11 library.

If a call to C_GetTokenInfo() returns the flag 
CKF_PROTECTED_AUTHENTICATION_PATH, then there's no PIN code to be sent in calls 
to C_Login(), C_SetPin(), C_InitToken(), etc. And the real authentication is 
device/vendor specific.

> Of course my app could check pkcs#11 library checksum and other mechanisms
> to "ensure" it is the library and not a proxy, but if my application is
> opensource (I'll love to), I'm fu*ked.
> 
> Is there any way to "trust" in the client? Can the server know the exe
> being executed is MY exe and an EVIL copy? (A private key embebed can also
> be cracked!)
> 
> Furthermore, our *lovely* card sends APDU for login in plainText, so anyone
> could see "1234" easily. And we are not able to establish a secure channel
> cause we lack the required keys.

And if you had the required keys, they would also be susceptible to theft, just 
as your previous private key.

> In the other hand, do you think is possible to "extend" WebcryptoAPI to
> generate/use keys to/from browser or system keystore?
> IMHO, how it actually works, sucks.

Technically, it's possible. But it doesn't seem to be a shared goal. Anyway, 
this wouldn't solve your initial problem.
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto