Re: [opensc-devel] Technical Description - Android Embedded SE

[Andreas Jellinghaus]

2012/9/22 NdK 

> Il 22/09/2012 12:41, Andreas Jellinghaus ha scritto:
>
> > In my mind keys could optionally contain application-oriented ACL
> > telling which
> > applications they trust so that even if you install a "bad" App, it
> > would for
> > example not be able to use your bank or eID-key in the background.
> In my mind, the SE should take over display and touch controller by
> hardware means, so absolutely no app can snoop user input or fake it.
> Too bad seems nobody really *needs* that level of security...
>

like "credsticks" from scifi novels decades ago? that owuld be a single use
appliance, and I think easy to hack, similar how it is trivial to have a
chip recording keystrokes placed inside a laptop etc. and I guess a multi
app would be extreme complex and unlikely to be secure either.

>
> > I must admit I don't know how many apps are managed and seperated. given
> > the restricted resources a smart card has,
> Think about how an MMU works: it keeps a table of "pages" assigned to an
> app, and maps 'em in app's address space. An app have no way to access a
> page outside its allowed address space. Nothing secret, here, and
> doesn't require great resources.
>

hmm, a datasheat I found on smartmx for example does not mention a MMU.
I guess it is onl a software implementation in the java interpreter, and
that could be well faulty.
also how are things managed - how easy is it to setup things wrong?

> I only remember seeing code that would change master keys and put one
> > app into a card, thus never bothered how it works in detail or how to
> > manage resource, secure apps against each other etc. Also I wonder: does
> > the vendor claim to have the security thight enough to prevent a hostile
> > app from accessing data of another app? Or is it the usual "all is
> > secure", but we don't tell how it works,
> > how to use it, and make no real guaranties anyway?
> Another question: if the applet manager is secure, then why change
> master keys before giving a card to customers?
>

cards go throug a pipeline of ~4 entities and everyone has his own secret
key that he doesn't want to give out.
first there is the chip key by the cpu vendor. then the mask of the OS
vendor has a different master key, so from
serial and the mask a new key is set. then the OS manufacturer changes the
key again as soon as he gets the hand
on the chips, as the cpu manufacturer can see the master key in the mask.
then he wants to send the chips to some
perso unit, so he has a master key agreed on between the os vendor and the
perso provider, and changes the card
key to be derviced from this. the perso provider could change the key again
when receiving the cards, but he needs
to trust the card or provider anyway, and might be too lazy. but once he
manufacturers a card, he has a master
key agreed on with the customer, e.g. a bank. and now the card key is
changed again. in this step the old key
is derived from the card serial, as in all previous steps, but the new key
is derived from the number of e.g. the visa card,
not the chip. again the bank could then change the cards key later, e.g.
using an update procedure in an ATM.
which noone does, because it never works well, but in theory ...

this procedure is not entirely accurate, as e.g. os vendors move towards
hosting equipment directly at the CPU manufacturer,
so the cards are changed on site, and can be directly send to perso units,
which will safe them manual extra work and one security transport - those
are quite expensive.

so for SE in mobile phones we would have the same more or less - e.g. NXP
does the chip and the OS (if the two units trust each other they can skip
one change to the key here), then the sell the chip to samsung and change
the key to the nxp-samsung-$chip MK derived one first, samsung might want
to change the key again, and sell the device. but if banks need to trust
the device enough to upload a smart card into it, then the end user can't
have the key for his device - otherwise he could decrypt the communication
and create several copies of the credit card uploaded, great for fraud, but
security of those depends on single unique cards.


> > My new impression is I would only need to use a smart card key&cert with
> > one site only - my SSO provider. Thus a plugin for that communication
> > only would work well with me.
> As long as you can import/export your cert (better if keeping it
> protected by a password) then you can have quite good security using
> openid and an identity provider like startssl that authenticates you
> using that cert.
>

certs don't need protection, only keys do. and being able to export a key
is always a bad idea.
it is much better to be able to get a new cert&key whenever you want on
demand. e.g. enter your credentials
(password, pin, tan, fingerprint, retina scan, secret handshake, whatever
you think is secure) and then get/generate
a new keypair and CSR and get the signed cert.

as for openid, I thou

Re: [opensc-devel] Technical Description - Android Embedded SE

[Andreas Jellinghaus]

2012/9/22 Anders Rundgren 

> On 2012-09-22 17:27, NdK wrote:
> > Il 22/09/2012 12:41, Andreas Jellinghaus ha scritto:
> >
> >> In my mind keys could optionally contain application-oriented ACL
> >> telling which
> >> applications they trust so that even if you install a "bad" App, it
> >> would for
> >> example not be able to use your bank or eID-key in the background.
>
> > In my mind, the SE should take over display and touch controller by
> > hardware means, so absolutely no app can snoop user input or fake it.
> > Too bad seems nobody really *needs* that level of security...
>
> The problem with that is that is impossible for a user to distinguish
> between a real PIN dialog and a fake ditto.  The SKS' "work-around" to
> this particular issue is that there is an OS-based PIN dialog and that
> keys can specify that they only accepts PINs through the system PIN dialog
> (trusted path).
>
> If the user is presented a spoofed PIN dialog, the attacker may indeed get
> the PIN.  However, the attacker must also take the device as well in order
> to use it which makes the attack much less useful.
>
> If the OS is hacked this doesn't help but it seems that this is not
> the biggest problem with mobile devices; it is rather determine what
> an app should be able to do or not.
>
> To get the proportions right, consumer security solutions should IMO be
> compared with the "Gold Standard" for Internet-payments where authorization
> is performed by a "UserID" (Card Number) and "Password" (CCV) printed in
> clear on plastic cards, which is all the Financial Industry have manged to
> roll out during the 15Y+ we have had with the Internet!
>

actually I think the system was doing fine - if you can review transactions
later
and refute any bogus transaction and the money can be traced to the
recipient,
and the system provider has a huge interest to keep the money traceable and
recall'able, that is a good system design, and protects everyone much
better than
technical adventures.

The downside from my perspective is rather that visa and master card are
shifting the liability to the end user.
if the only one in the system who can enforce security standards is no
longer liable to carry the burdon of not having
a good enough security, then the system is going bad. verified by VISA and
the similar master card initiative require
the end user to verify each transaction with an additional password. If it
is a password, it can be sniffed by a trojan
as easily. if it is a TAN send over a SMS to your mobile phone, then
loosing you mobile phone means an empty
bank account.

Lets be honest: you might have your mobile phone and wallet in your
hand-bag or backpack or whatever, and if
both are stolen the attacker has access to about everything and almost all
ways to identify you and authorize
transactions are in his hand. even the numbers you might need to know to
prevent fraud are no longer with you -
e.g. in germany I might remember the central hotline for reporting stolen
cards (116 116) and I remember my bank
account number. but if they require my visa card number, I wouldn't know
that. also I wouldn't have mobile phone
with me - it got stolen - and if I don't notice the issue I'm out of luck,
as everyone (banks, telco, ...) shift the liability
for every transaction until the theft gets reported to the customer.

the mobile phones have authentication of the customer (gesture, pin,
password or screen unlock), but those are not very good protections. so my
expectation is they won't stop attackers.

Andreas


>
> Anders
>
>
> >
> >> I must admit I don't know how many apps are managed and seperated. given
> >> the restricted resources a smart card has,
> > Think about how an MMU works: it keeps a table of "pages" assigned to an
> > app, and maps 'em in app's address space. An app have no way to access a
> > page outside its allowed address space. Nothing secret, here, and
> > doesn't require great resources.
> >
> >> I only remember seeing code that would change master keys and put one
> >> app into a card, thus never bothered how it works in detail or how to
> >> manage resource, secure apps against each other etc. Also I wonder: does
> >> the vendor claim to have the security thight enough to prevent a hostile
> >> app from accessing data of another app? Or is it the usual "all is
> >> secure", but we don't tell how it works,
> >> how to use it, and make no real guaranties anyway?
> > Another question: if the applet manager is secure, then why change
> > master keys before giving a card to customers?
> >
> >> My new impression is I would only need to use a smart card key&cert with
> >> one site only - my SSO provider. Thus a plugin for that communication
> >> only would work well with me.
> > As long as you can import/export your cert (better if keeping it
> > protected by a password) then you can have quite good security using
> > openid and an identity provider like startssl that authenticates you
> > using that

Re: [opensc-devel] Technical Description - Android Embedded SE

[Anders Rundgren]

On 2012-09-23 12:04, Andreas Jellinghaus wrote:
> 2012/9/22 Anders Rundgren  >
> 
> On 2012-09-22 17:27, NdK wrote:
> > Il 22/09/2012 12:41, Andreas Jellinghaus ha scritto:
> >
> >> In my mind keys could optionally contain application-oriented ACL
> >> telling which
> >> applications they trust so that even if you install a "bad" App, it
> >> would for
> >> example not be able to use your bank or eID-key in the background.
> 
> > In my mind, the SE should take over display and touch controller by
> > hardware means, so absolutely no app can snoop user input or fake it.
> > Too bad seems nobody really *needs* that level of security...
> 
> The problem with that is that is impossible for a user to distinguish
> between a real PIN dialog and a fake ditto.  The SKS' "work-around" to
> this particular issue is that there is an OS-based PIN dialog and that
> keys can specify that they only accepts PINs through the system PIN dialog
> (trusted path).
> 
> If the user is presented a spoofed PIN dialog, the attacker may indeed get
> the PIN.  However, the attacker must also take the device as well in order
> to use it which makes the attack much less useful.
> 
> If the OS is hacked this doesn't help but it seems that this is not
> the biggest problem with mobile devices; it is rather determine what
> an app should be able to do or not.
> 
> To get the proportions right, consumer security solutions should IMO be
> compared with the "Gold Standard" for Internet-payments where 
> authorization
> is performed by a "UserID" (Card Number) and "Password" (CCV) printed in
> clear on plastic cards, which is all the Financial Industry have manged to
> roll out during the 15Y+ we have had with the Internet!
> 
> 
> actually I think the system was doing fine - if you can review transactions 
> later
> and refute any bogus transaction and the money can be traced to the recipient,
> and the system provider has a huge interest to keep the money traceable and
> recall'able, that is a good system design, and protects everyone much better 
> than
> technical adventures.

I guess you refer to the Google Wallet or SKS as "technical adventures"?  I 
don't
see any conflicts between judicious logging and systems that [rightly or 
wrongly]
are claimed to be more secure than passwords printed in clear on plastic cards.

> 
> The downside from my perspective is rather that visa and master card are 
> shifting the liability to the end user.
> if the only one in the system who can enforce security standards is no longer 
> liable to carry the burdon of not having
> a good enough security, then the system is going bad. verified by VISA and 
> the similar master card initiative require
> the end user to verify each transaction with an additional password. If it is 
> a password, it can be sniffed by a trojan
> as easily. if it is a TAN send over a SMS to your mobile phone, then loosing 
> you mobile phone means an empty
> bank account.

3D Secure IMO combines the worst possible user-interface with questionable 
security.
However, the concept is actually brilliant but it will rather be Google and 
Apple
that will make it useful, not MasterCard and VISA.

> 
> Lets be honest: you might have your mobile phone and wallet in your hand-bag 
> or backpack or whatever, and if
> both are stolen the attacker has access to about everything and almost all 
> ways to identify you and authorize
> transactions are in his hand. even the numbers you might need to know to 
> prevent fraud are no longer with you -
> e.g. in germany I might remember the central hotline for reporting stolen 
> cards (116 116) and I remember my bank
> account number. but if they require my visa card number, I wouldn't know 
> that. also I wouldn't have mobile phone
> with me - it got stolen - and if I don't notice the issue I'm out of luck, as 
> everyone (banks, telco, ...) shift the liability
> for every transaction until the theft gets reported to the customer.
> 
> the mobile phones have authentication of the customer (gesture, pin, password 
> or screen unlock), but those are not
> very good protections. so my expectation is they won't stop attackers.

I expect another kind of protection to be more useful and that is that the 
owner will be able
to set it "on hold" or possibly even in "wipe out" mode through a cloud service 
that the phone will
interrogate every now and then.  If the cloud service isn't available you must 
issue a "difficult"
password before gaining access to the device.  From what I can deduct from the 
rather scarce
Wallet documents, this is more or less already in place.  If the device is 
subject to a shrewd
attack I guess only the traditional credential revocation will help.  The cloud 
service may
aid you with that as well.

I definitely believe that losing a mobile phone wallet will be less dev

[opensc-devel] pkcs11-helper missing export of pkcs11h_token_logout symbol

[Eric Dorland]

Howdy,

This was reported by a Debian user, and it looks like just a missing
export of the symbol. The attached patch should fix things.

-- 
Eric Dorland 
ICQ: #61138586, Jabber: ho...@jabber.com

diff --git a/lib/token.exports b/lib/token.exports
index 9ac673b..42fa27c 100644
--- a/lib/token.exports
+++ b/lib/token.exports
@@ -5,5 +5,6 @@ pkcs11h_token_enumTokenIds
 pkcs11h_token_freeTokenId
 pkcs11h_token_freeTokenIdList
 pkcs11h_token_login
+pkcs11h_token_logout
 pkcs11h_token_sameTokenId
 pkcs11h_token_serializeTokenId


signature.asc
Description: Digital signature
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] Domain Parameter for ECC Keys

[Andreas Schwier]

Hi Douglas,

see below.

Andreas


Am 20.09.2012 17:12, schrieb Douglas E. Engert:
>
> On 9/19/2012 6:11 PM, Andreas Schwier (ML) wrote:
>> Dear all,
>>
>> we've come across a strange behaviour of the pkcs15-lib in OpenSC when
>> we generate an EC key pair:
>>
>> After generating an fresh EC key pair, our code returns a
>> sc_pkcs15_pubkey containing the EC public key and DER encoded domain
>> parameter. The public key is then encoded in sc_pkcs15init_generate_key
>> and added to the DF in the framework when it's immediately decoded again.
>>
>> During this encode / decode step the domain parameter are lost.
> Looked at PKCS#15 v1.1 section 6.4.3 The value is a EC_PubKeyChoice, that
> can be a raw ECPoint or a spki SubjectPublicKeyInfo.
>
> It looks like the sc_pkcs15_encode_pubkey_ec is just returning the
> ECPoint.
>
> sc_pkcs15_decode_pubkey_ec is also assuming the ECPoint.
>
> It looks like that code has never been fully tested, and the
> above code should be modified to use the spki SubjectPublicKeyInfo
> if there are domain parameters.
>
> With the EC work I have done in OpenSC including writing the above two
> routines, I have not looked at the pkcs15init code at all, as the PIV
> card is not a PKCS#15 card but rather the PKCS#15 is emulated, and the
> emulation layer is base on the decoded entries. The PIV  does not use the
> pkcs15init code at all, but rather a special pivtool can be used for test
> cards to generate a key. It also turns out that the PIV card does not store
> a pubkey object at all, but derives the pubkey from the certificate.
>
>> I'm wondering why this encode / decode step is done ?
> No one has a PKCS#15 cards that support EC to test this part of the code.
We do have a card that supports EC ;-)
>
>> If it is required for some reason, then I would rather encode the public
>> key in SubjectPublicKey structure that would also preserve the domain
>> parameter in AlgorithmIdentifier.
> Can you come up with a patch?
Yes, we can certainly do that. I just wanted to make sure that I
understand the rational behind the current implementation.
>
>> Andreas
>>


-- 

-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

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel