Re: [opensc-devel] Technical Description - Android Embedded SE
On Sun, Sep 30, 2012 at 5:48 AM, NdK ndk.cla...@gmail.com wrote: Il 29/09/2012 09:01, Frank Cusack ha scritto: I knew something that didn't need trusted software (in the PC) should exist. And Finally I found it: http://www.ftsafe.com/product/epass/interpass Seems quite near to my idea of a really-smart card: big display to show transaction details and button to review/confirm/cancel (and, I hope, to insert a gesture that replaces the PIN...). Just evolve that a bit and it's perfect :) I agree, it's close. Not that I've contacted them, but I doubt it's an actual shipping product. I've already seen a smartcard that hosts a battery, a display and a button in a standard ISO form factor (it uses the sc chip to henerate an OTP every time the key is pressed), so 'technically' we're quite near to a card that shows anamount to be authorized and a blinding factor for the PIN (5 digits, to be added one-to one to the actual PIN, so snooping the keyboard is useless), or even having an integrated pinpad to enter the PIN w/o relying on an external device. Sure. I built [prototypes of] such a card 6+ years ago, minus the PINpad. There are at least 2 vendors of such cards today, and at least one vendor of a card that includes a PINpad. $$$ and very niche. Also, no one really wants to use such a card. So there's no question it can be built in USB form factor. But I don't believe there are any customers and so the product is not actually shipping. It would take the first customer to commit, before they built it. Someone here must be on a first-name-basis with someone at Feitian? ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Technical Description - Android Embedded SE
On 2012-10-02 06:36, Frank Cusack wrote: . I've already seen a smartcard that hosts a battery, a display and a button in a standard ISO form factor (it uses the sc chip to henerate an OTP every time the key is pressed), so 'technically' we're quite near to a card that shows anamount to be authorized and a blinding factor for the PIN (5 digits, to be added one-to one to the actual PIN, so snooping the keyboard is useless), or even having an integrated pinpad to enter the PIN w/o relying on an external device. Sure. I built [prototypes of] such a card 6+ years ago, minus the PINpad. There are at least 2 vendors of such cards today, and at least one vendor of a card that includes a PINpad. $$$ and very niche. Also, no one really wants to use such a card. So there's no question it can be built in USB form factor. But I don't believe there are any customers and so the product is not actually shipping. It would take the first customer to commit, before they built it. Someone here must be on a first-name-basis with someone at Feitian? The lack of usable enrollment schemes for smart cards make them a poor choice for mass markets like phones. It was fun as long as it lasted as I say :-) Android 6 and iPhone 7 won't even have SIM-card slots. Anders ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Technical Description - Android Embedded SE
Il 29/09/2012 09:01, Frank Cusack ha scritto: I knew something that didn't need trusted software (in the PC) should exist. And Finally I found it: http://www.ftsafe.com/product/epass/interpass Seems quite near to my idea of a really-smart card: big display to show transaction details and button to review/confirm/cancel (and, I hope, to insert a gesture that replaces the PIN...). Just evolve that a bit and it's perfect :) I agree, it's close. Not that I've contacted them, but I doubt it's an actual shipping product. I've already seen a smartcard that hosts a battery, a display and a button in a standard ISO form factor (it uses the sc chip to henerate an OTP every time the key is pressed), so 'technically' we're quite near to a card that shows anamount to be authorized and a blinding factor for the PIN (5 digits, to be added one-to one to the actual PIN, so snooping the keyboard is useless), or even having an integrated pinpad to enter the PIN w/o relying on an external device. Too bad that producing such a card would require a big rethinking (well, not too big, since something already exists along that lines), and that costs quite a lot... EMV could surely do that, an hobbyist no (unless his name is Bill Gates). BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Technical Description - Android Embedded SE
On Fri, Sep 21, 2012 at 11:58 PM, Andreas Jellinghaus andr...@ionisiert.dewrote: Am 20.09.2012 21:06 schrieb Anders Rundgren anders.rundg...@telia.com: http://nelenkov.blogspot.se/2012/08/accessing-embedded-secure-element-in.html Very interesting IMHO. Agree, thanks for sharing. According to the author SD-slots are becoming exceptions also for Android so this is probably what most people will be dealing with. I think he is also over optimistic with multi applications on a Java card SE, but we will see. I didn't catch any references to that in the linked article, but if I missed it or he discusses it elsewhere, I agree. Certainly on an android phone I don't believe we'll ever see the day when the user can install his own application on the phone SE. On Sat, Sep 22, 2012 at 1:18 AM, Anders Rundgren anders.rundg...@telia.comwrote: I even wonder if the SE needs to host applications at all. IMO, it would be enough if the SE hosts keys and associated attributes while the applications either rather run at OS-level as trusted processes like PIN input etc. or as standard applications. As far as I understand the Wallet is just an Android App that is trusted by the SE. Indeed, the SE need not host applications, but it depends on your application. For example a wallet (of the digital cash variety) needs to run code, not just host keys. The Google wallet isn't digital cash but it's still an SE applet, not an Android app. (So your understanding is wrong.) 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. ACL would however be at the mercy of the phone OS, so you've now expanded the trust boundary so that kind of control defeats the purpose of an ACL. Or perhaps you have confused me here with App: if you meant applet that runs on the SE, then in that case ACLs are useful, however since you have to interact via the phone you are still at the mercy of the phone OS. On Sat, Sep 22, 2012 at 3:41 AM, Andreas Jellinghaus andr...@ionisiert.dewrote: I must admit I don't know how many apps are managed and seperated. given the restricted resources a smart card has, I assume there is a master key that creates contain of specific sizes/dimensions/... and the app is loaded into such a container, limiting it and reserving the unallocated space for further applications/containers? That's exactly right. Is there a standard on doing this, or is it all JCOP magic under NDA? It's part of Global Platform. On Sat, Sep 22, 2012 at 8:27 AM, NdK ndk.cla...@gmail.com wrote: 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. I agree. Too bad seems nobody really *needs* that level of security... I disagree, we all NEED that level of security. It's just that security isn't a mature thing yet so we're just not there yet. Note that Intel and ARM both have such technologies today. On Sun, Sep 23, 2012 at 2:52 AM, Andreas Jellinghaus andr...@ionisiert.dewrote: - cards were incompatible forever, but now mostly JCOP survives and everyone else stopped improving their cards? I haven't seen many new card operating systems released in the last years at least. and at least for small developers I'm not aware that you can buy other java cards than JCOP. There are a small but reasonable number of smart card OSes you can buy today. There aren't any that small developers can work with, but that's just a consequence of how that market works and it isn't going to change. And JCOP again is a prime example of a NDA thing, not a standard, right? or did it improve? JavaCard is a standard. JCOP is an implementation of that standard. On Thu, Sep 27, 2012 at 12:37 PM, NdK ndk.cla...@gmail.com wrote: I knew something that didn't need trusted software (in the PC) should exist. And Finally I found it: http://www.ftsafe.com/product/epass/interpass Seems quite near to my idea of a really-smart card: big display to show transaction details and button to review/confirm/cancel (and, I hope, to insert a gesture that replaces the PIN...). Just evolve that a bit and it's perfect :) I agree, it's close. Not that I've contacted them, but I doubt it's an actual shipping product. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Technical Description - Android Embedded SE
On 2012-09-29 09:01, Frank Cusack wrote: On Fri, Sep 21, 2012 at 11:58 PM, Andreas Jellinghaus andr...@ionisiert.de mailto:andr...@ionisiert.de wrote: Am 20.09.2012 21:06 schrieb Anders Rundgren anders.rundg...@telia.com mailto:anders.rundg...@telia.com: http://nelenkov.blogspot.se/2012/08/accessing-embedded-secure-element-in.html Very interesting IMHO. Agree, thanks for sharing. According to the author SD-slots are becoming exceptions also for Android so this is probably what most people will be dealing with. I think he is also over optimistic with multi applications on a Java card SE, but we will see. I didn't catch any references to that in the linked article, but if I missed it or he discusses it elsewhere, I agree. Certainly on an android phone I don't believe we'll ever see the day when the user can install his own application on the phone SE. Right. There is no point in installing applications in the SE; applications are installed on top of the OS. The SE only needs to keep keys (like smart cards in reality do ..) . Keys OTOH will presumably be possible to deploy by anybody the day Google dumps GlobalPlatform. Anders On Sat, Sep 22, 2012 at 1:18 AM, Anders Rundgren anders.rundg...@telia.com mailto:anders.rundg...@telia.com wrote: I even wonder if the SE needs to host applications at all. IMO, it would be enough if the SE hosts keys and associated attributes while the applications either rather run at OS-level as trusted processes like PIN input etc. or as standard applications. As far as I understand the Wallet is just an Android App that is trusted by the SE. Indeed, the SE need not host applications, but it depends on your application. For example a wallet (of the digital cash variety) needs to run code, not just host keys. The Google wallet isn't digital cash but it's still an SE applet, not an Android app. (So your understanding is wrong.) 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. ACL would however be at the mercy of the phone OS, so you've now expanded the trust boundary so that kind of control defeats the purpose of an ACL. Or perhaps you have confused me here with App: if you meant applet that runs on the SE, then in that case ACLs are useful, however since you have to interact via the phone you are still at the mercy of the phone OS. On Sat, Sep 22, 2012 at 3:41 AM, Andreas Jellinghaus andr...@ionisiert.de mailto:andr...@ionisiert.de wrote: I must admit I don't know how many apps are managed and seperated. given the restricted resources a smart card has, I assume there is a master key that creates contain of specific sizes/dimensions/... and the app is loaded into such a container, limiting it and reserving the unallocated space for further applications/containers? That's exactly right. Is there a standard on doing this, or is it all JCOP magic under NDA? It's part of Global Platform. On Sat, Sep 22, 2012 at 8:27 AM, NdK ndk.cla...@gmail.com mailto:ndk.cla...@gmail.com wrote: 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. I agree. Too bad seems nobody really *needs* that level of security... I disagree, we all NEED that level of security. It's just that security isn't a mature thing yet so we're just not there yet. Note that Intel and ARM both have such technologies today. On Sun, Sep 23, 2012 at 2:52 AM, Andreas Jellinghaus andr...@ionisiert.de mailto:andr...@ionisiert.de wrote: - cards were incompatible forever, but now mostly JCOP survives and everyone else stopped improving their cards? I haven't seen many new card operating systems released in the last years at least. and at least for small developers I'm not aware that you can buy other java cards than JCOP. There are a small but reasonable number of smart card OSes you can buy today. There aren't any that small developers can work with, but that's just a consequence of how that market works and it isn't going to change. And JCOP again is a prime example of a NDA thing, not a standard, right? or did it improve? JavaCard is a standard. JCOP is an implementation of that standard. On Thu, Sep 27, 2012 at 12:37 PM, NdK ndk.cla...@gmail.com mailto:ndk.cla...@gmail.com wrote: I knew something that didn't need trusted software (in the PC) should exist. And Finally I found it: http://www.ftsafe.com/product/epass/interpass Seems quite near to my idea of a really-smart card: big display to show transaction details and button to review/confirm/cancel (and, I hope, to
Re: [opensc-devel] Technical Description - Android Embedded SE
On Sat, Sep 29, 2012 at 12:40 AM, Anders Rundgren anders.rundg...@telia.com wrote: Right. There is no point in installing applications in the SE; applications are installed on top of the OS. The SE only needs to keep keys (like smart cards in reality do ..) . That's a very limited use of the SE. Keys OTOH will presumably be possible to deploy by anybody the day Google dumps GlobalPlatform. Global Platform is completely orthogonal. Keys could be deployed today with or without GP if Google wanted to allow it. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Technical Description - Android Embedded SE
On 2012-09-29 18:23, Frank Cusack wrote: On Sat, Sep 29, 2012 at 12:40 AM, Anders Rundgren anders.rundg...@telia.com mailto:anders.rundg...@telia.com wrote: Right. There is no point in installing applications in the SE; applications are installed on top of the OS. The SE only needs to keep keys (like smart cards in reality do ..) . That's a very limited use of the SE. There are other uses such a supporting secure boot but having things like payment applications in the SE looks to me like a moderately useful idea since the SE doesn't come with a GUI. Keys OTOH will presumably be possible to deploy by anybody the day Google dumps GlobalPlatform. Global Platform is completely orthogonal. Keys could be deployed today with or without GP if Google wanted to allow it. Is that so? Since Google most likely use a symmetric management key an external party cannot use secure messaging and then the whole SE idea becomes very uninteresting. Anders ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Technical Description - Android Embedded SE
2012/9/27 Martin Paljak mar...@martinpaljak.net On Sat, Sep 22, 2012 at 1:41 PM, Andreas Jellinghaus andr...@ionisiert.de wrote: 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. I must admit I don't know how many apps are managed and seperated. given the restricted resources a smart card has, I assume there is a master key that creates contain of specific sizes/dimensions/... and the app is loaded into such a container, limiting it and reserving the unallocated space for further applications/containers? Is there a standard on doing this, or is it all JCOP magic under NDA? Are you referring to GlobalPlatform? That's public, with docs and API references (when applicable) available on globalplatform.org. I thought JCOP had more commands than GlobalPlattform, e.g. to manage card specific settings (e.g. change the ATR and communication settings). I bet there are probably vendors who tweak/amend/change/molest the spec, but the general principles should be there and followed by many vendors. There is an interesting thing called Trusted Execution Environment that might come to existence some time in the future, called TEE: http://www.globalplatform.org/documents/GlobalPlatform_TEE_White_Paper_Feb2011.pdf But for a mobile solutions and experiences, I think the time now is as good as pre-CCID for smart card readers: wild-wild-west and with a *much* tougher competition situation. Who needs standards if you have an iPhone :) Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Technical Description - Android Embedded SE
Il 23/09/2012 12:04, Andreas Jellinghaus ha scritto: 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). I knew something that didn't need trusted software (in the PC) should exist. And Finally I found it: http://www.ftsafe.com/product/epass/interpass Seems quite near to my idea of a really-smart card: big display to show transaction details and button to review/confirm/cancel (and, I hope, to insert a gesture that replaces the PIN...). Just evolve that a bit and it's perfect :) BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Technical Description - Android Embedded SE
Il 25/09/2012 07:58, Andreas Jellinghaus ha scritto: EMV for sure: there's an unauthenticated bit that tells the card to authenticate the transaction without asking for the PIN... Thats ok, it is a valid feature. If people buy something for less than a dollar, and the transaction is authenticated with the signature of a rsa key in the smart card, and we haven't reached the consecutive lower boundary amount yet, then simply approving the transaction is perfectly fine - getting a PIN or doing an online transaction isn't worth doing for such a small amount of money. IIUC that bit is not authenticated, so a MITM attack can force both the reader and the card think the other party doesn't support PIN auth, making the card sign the transaction anyway, regardless the amount involved. So IMVHO it's quite serious... Most vending machines still use modems and dial up for every transaction and hang up again later. The stupid thing is that it seems they do the same for cellular-based readers too... What a waste! Thats why card transactions are so slow. Once the standard is to have a permanent internet connection, that won't change anything: many banks still use *mainframes* ! Some still backup to (and transfer data with) tape *wheels* ! (when we dismissed our IBM 9000, I think one of the tape units got sold to the bank...). As long as it works, they don't change it. BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Technical Description - Android Embedded SE
NdK wrote: IIUC that bit is not authenticated, so a MITM attack can force both the reader and the card think the other party doesn't support PIN auth, making the card sign the transaction anyway, regardless the amount involved. So IMVHO it's quite serious... http://www.cl.cam.ac.uk/~sjm217/papers/oakland10chipbroken.pdf http://youtu.be/gv3dxjvqk7Y //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Technical Description - Android Embedded SE
Il 25/09/2012 11:50, Peter Stuge ha scritto: IIUC that bit is not authenticated, so a MITM attack can force both the reader and the card think the other party doesn't support PIN auth, making the card sign the transaction anyway, regardless the amount involved. So IMVHO it's quite serious... http://www.cl.cam.ac.uk/~sjm217/papers/oakland10chipbroken.pdf Tks. That's the (or one of) article I remembered but couldn't find... BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Technical Description - Android Embedded SE
NdK wrote: IIUC that bit is not authenticated, so a MITM attack can force both the reader and the card think the other party doesn't support PIN auth, making the card sign the transaction anyway, regardless the amount involved. So IMVHO it's quite serious... http://www.cl.cam.ac.uk/~sjm217/papers/oakland10chipbroken.pdf Tks. That's the (or one of) article I remembered but couldn't find... http://google.com/search?q=chip+and+pin+broken ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Technical Description - Android Embedded SE
2012/9/25 Peter Stuge pe...@stuge.se NdK wrote: IIUC that bit is not authenticated, so a MITM attack can force both the reader and the card think the other party doesn't support PIN auth, making the card sign the transaction anyway, regardless the amount involved. So IMVHO it's quite serious... http://www.cl.cam.ac.uk/~sjm217/papers/oakland10chipbroken.pdf Tks. That's the (or one of) article I remembered but couldn't find... http://google.com/search?q=chip+and+pin+broken but the broken security demonstrated so far is related to misconfiguration, and many other banks have correct card profiles and are not affected. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Technical Description - Android Embedded SE
Il 22/09/2012 19:37, Anders Rundgren ha scritto: 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). That's quite easy to avoid: once the SE takes over the display, it can prompt the user with an user-supplied message . Visa is doing something similar with securecode auth: when you're doing a payment, you get redirected to their site, where you see a personalized prompt and have to enter another password. If you don't see your own prompt, you don't enter the password.. 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. The only drawback would be that if the attacker, after stealing the phone and hacking it to include the right message in the spoofer, returns it to the legit user, waits for the spoof to intercept the PIN and then steals it again... Quite unlikely :) and easily detectable: if your phone disappeared, change the prompt before connecting again to the payment service: if you still see the old prompt, better to reflash the phone and change *all* your passwords. 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. If SE takes over HW access (this could include accelerometers, since they could be used to infer where the user is tapping -- paranoid enoug?), then it can be secure even if the OS got hacked. BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Technical Description - Android Embedded SE
Il 23/09/2012 11:52, Andreas Jellinghaus ha scritto: 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. Nope. Speaking of SE in smartphones here :) You don't have much space inside a phone... Hopefully not enough to add a logger chip. And a phone is really much more tamper evident than a laptop... 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. Software-emulated MMU, then. Since it's so simple, it could well be worth the reduction in gates at the expense of a little longer run time -- but you are already running java, not optimized asm... also how are things managed - how easy is it to setup things wrong? That should be impossible, if the card only allows fixed-size apps and went under throrought testing. 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 [...] Uhm... Found. If the key was publicly known, a reseller could easily remove an applet and replace it with another using the same app id and the final user wouldn't be able to know. If only the card manager would allow a per-app removal key... My new impression is I would only need to use a smart card keycert 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. Unless you either can set up a multi-party RSA system or have another way to recover a damaged key. If exporting keys is always such a bad idea, then why root-CAs export theirs? Simply to have a backup and obtain business continuity in case of HSM failure. it is much better to be able to get a new certkey 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. Unless you run a CA. :) as for openid, I thought there was some discussion about it - v1 too complex, not much agreement on v2 or so? Complex? Seems quite easy... Always too many things under NDA or plainly unavailable, too often starting from comm specs... comm=communication , sorry. common specs? I rather wonder: everyone invented something on his own, and when a standard came around, any change would break compatibility and more important require new certification rounds, thus would be expensive, thus everyyone preferred to not implement the standard. after all who wants to give users the choice to switch vendors? very bad idea, vendor lockin is king, I'm still waiting for ACS to tell me something about how can I use my cryptomate64 token. I could have its reader recognized, but ACOS5 protocol is still unsupported (I found a project, but it seems still in its early stages...). other java cards than JCOP. And JCOP again is a prime example of a NDA thing, not a standard, right? or did it improve? I have some JCOP cards, but just lately I found how to authenticate with the card manager using Alexander Petric's hints for gpshell. If I have't to sign NDAs to develop my own applets and load'em on card, then for me it's open enough. But I still don't know if I have enough info (for example: how do I handle RSA crypto? I hope there's a library with public API for that...). BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Technical Description - Android Embedded SE
2012/9/23 Anders Rundgren anders.rundg...@telia.com On 2012-09-23 12:04, Andreas Jellinghaus wrote: 2012/9/22 Anders Rundgren anders.rundg...@telia.com mailto: anders.rundg...@telia.com 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. no, I was refering to all the magic solutions that make things secure suddenly. Like sms-tan instead of pin+tan, or funny devices reading flickering info on some banks online system, or smart cards with biometrics on board, or $government-identified-super-secure-signing-cards or stupid de-mail (email with a postage cost of half an euro) which they try to sell in germany, and all this stuff. switching from magstripe to EMV transactions (chip+pin) seams to be a good idea though, as magstripe is totaly unsecure. but the real foundation of the credit card business is the middle man that vouches against both user and shop for any loss, and runs a fraud prevention programm to minimize risk and cost. this idea is great, technical solutions are perfectly fine, if they keep this basic system. I complain that they try to do not. EMV is of course totaly bloated and thus far too complex, and the whole idea of visa and mastercard keeping paypass and paywave confidential, even partners under NDA only get to see their bits, that is real stupid and insecure. I wonder how many years we need until people are willing to build an online only system. that won't work offline, but could be soo much easier than the offline system. many banks have already moved e.g. their PINs from the card to the online system, as unblocking a PIN in a card was often not working well, and having a central manged IT is much easier. So banks are already willing to restrict at least certain functions like debit (cash from ATM) to online only. 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. well, no nfc in iphone5, thus no idea what plans Apple has, and I can't comment on
Re: [opensc-devel] Technical Description - Android Embedded SE
2012/9/24 NdK ndk.cla...@gmail.com Il 23/09/2012 11:52, Andreas Jellinghaus ha scritto: 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. Nope. Speaking of SE in smartphones here :) well, that is lots of software in the smart phone that can be hacked. not a secure entry device from my point of view. You don't have much space inside a phone... Hopefully not enough to add a logger chip. And a phone is really much more tamper evident than a laptop... hmm, not so sure about that. but even if that is true, the software is easier to hack anyway, and requires only installing the wrong app try this game, thus has a much easier attack vector. 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. Software-emulated MMU, then. Since it's so simple, it could well be worth the reduction in gates at the expense of a little longer run time -- but you are already running java, not optimized asm... well, in the end your programm is pretty simple I guess, and the complex operations like crypto are in a library in the chip and not java bytecode. also how are things managed - how easy is it to setup things wrong? That should be impossible, if the card only allows fixed-size apps and went under throrought testing. well, we saw so many insecurities in smart cards in the last few years - e.g. the hacks on mifare and legic, or the flaws found by ross anderson and his team on EMV cards - I doubt things are really secure, if they are very complex. 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 [...] Uhm... Found. If the key was publicly known, a reseller could easily remove an applet and replace it with another using the same app id and the final user wouldn't be able to know. If only the card manager would allow a per-app removal key... well. who is the card manager. if I buy a phone without contract, is it the vendor? if I buy a phone with a contract, is it the mobile network operator? will we have conflicts of interest? we already have locked phones and preventing some functionality (voice over ip, tethering, ...), and I guess phone companies want you to pay with your phone - as long as it ends up on the phone bill and they get a share of each transaction? thus who controls the SE has power, and it can't be you the end user, as the bank won't trust you to do a secure deployment. My new impression is I would only need to use a smart card keycert 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. Unless you either can set up a multi-party RSA system or have another way to recover a damaged key. no one needs to recover keys. simply create a new one and create a new cert. If exporting keys is always such a bad idea, then why root-CAs export theirs? Simply to have a backup and obtain business continuity in case of HSM failure. HSM have all keys stored on the normal windows disk - but encrypted. the encryption is with AES or 3DES, and that is a master key that can be loaded into several HSM. often it is an XOR of N master key parts, and 4*N different persons have a copy of one part (two sites, two person each site). Thus worst case any copy of the key database plus parts 1..N can be used to setup a fresh HSM with the same master key and keep using those keys. standard practice for IBM HSMs at least I believe. it is much better to be able to get a new certkey 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. Unless you run a CA. :) no. if you run a CA creating new certificates costs you nothing, so the best thing you can do for security is short lived certificates with fast automated secure refresh cycles. the reason why people have long lived certificates, is because it is such a hassle to create new ones and manage
Re: [opensc-devel] Technical Description - Android Embedded SE
Il 24/09/2012 21:37, Andreas Jellinghaus ha scritto: no, I was refering to all the magic solutions that make things secure suddenly. there was a good comic strip I can't find just now... Hackers view: oh, no, this laptop is protected by 4096-bit RSA... no way we can recover it even with $100! Grunt view: this laptop is locked... take this $5 wrench and beat off the pass from the user. Too bad it proves right... Here in Italy we've had many episodes of people kidnapped to make their families let robbers enter well-protected houses... :( Like sms-tan instead of pin+tan, or funny devices reading flickering info on some banks online system, or smart cards with biometrics on board, or $government-identified-super-secure-signing-cards or stupid de-mail (email with a postage cost of half an euro) which they try to sell in germany, and all this stuff. Not to speak of italian posta certificata (certified mail, with provable delivery so that it can have legal value)... :) EMV is of course totaly bloated and thus far too complex, and the whole idea of visa and mastercard keeping paypass and paywave confidential, even partners under NDA only get to see their bits, that is real stupid and insecure. Maybe because they know it's not secure? EMV for sure: there's an unauthenticated bit that tells the card to authenticate the transaction without asking for the PIN... BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Technical Description - Android Embedded SE
2012/9/25 NdK ndk.cla...@gmail.com Il 24/09/2012 21:37, Andreas Jellinghaus ha scritto: no, I was refering to all the magic solutions that make things secure suddenly. there was a good comic strip I can't find just now... Hackers view: oh, no, this laptop is protected by 4096-bit RSA... no way we can recover it even with $100! Grunt view: this laptop is locked... take this $5 wrench and beat off the pass from the user. Too bad it proves right... Here in Italy we've had many episodes of people kidnapped to make their families let robbers enter well-protected houses... :( Like sms-tan instead of pin+tan, or funny devices reading flickering info on some banks online system, or smart cards with biometrics on board, or $government-identified-super-secure-signing-cards or stupid de-mail (email with a postage cost of half an euro) which they try to sell in germany, and all this stuff. Not to speak of italian posta certificata (certified mail, with provable delivery so that it can have legal value)... :) EMV is of course totaly bloated and thus far too complex, and the whole idea of visa and mastercard keeping paypass and paywave confidential, even partners under NDA only get to see their bits, that is real stupid and insecure. Maybe because they know it's not secure? No, I think it is well intended - try to be compatible with every old thing and have all the features everyone wants in there. Except the result of such a process is not good. EMV for sure: there's an unauthenticated bit that tells the card to authenticate the transaction without asking for the PIN... Thats ok, it is a valid feature. If people buy something for less than a dollar, and the transaction is authenticated with the signature of a rsa key in the smart card, and we haven't reached the consecutive lower boundary amount yet, then simply approving the transaction is perfectly fine - getting a PIN or doing an online transaction isn't worth doing for such a small amount of money. Most vending machines still use modems and dial up for every transaction and hang up again later. Thats why card transactions are so slow. Once the standard is to have a permanent internet connection, the cost of doing an online transaction is lower (less delay) and the profile could be changed to do everything online. But since the card doesn't know where it is, it can only have a world wide setting, and people expect the card to work in the remote places with the worst infrastructure. Maybe some day banks want to give people two credit cards with different settings? Andreas BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Technical Description - Android Embedded SE
2012/9/22 NdK ndk.cla...@gmail.com 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 keycert 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 certkey 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 thought there was some discussion about it -
Re: [opensc-devel] Technical Description - Android Embedded SE
2012/9/22 Anders Rundgren anders.rundg...@telia.com 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 keycert 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. Not sure what to do about phone theft though - I really fear putting all the access
Re: [opensc-devel] Technical Description - Android Embedded SE
On 2012-09-23 12:04, Andreas Jellinghaus wrote: 2012/9/22 Anders Rundgren anders.rundg...@telia.com mailto:anders.rundg...@telia.com 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 devastating than losing a traditional one. Naturally it has to be proved. I
Re: [opensc-devel] Technical Description - Android Embedded SE
Am 20.09.2012 21:06 schrieb Anders Rundgren anders.rundg...@telia.com: http://nelenkov.blogspot.se/2012/08/accessing-embedded-secure-element-in.html Very interesting IMHO. Agree, thanks for sharing. According to the author SD-slots are becoming exceptions also for Android so this is probably what most people will be dealing with. I think he is also over optimistic with multi applications on a Java card SE, but we will see. The NFC chip should be similar to what can be used with libnfc, so porting all the mifare copy clone and fake tools would be awesome... Andreas Anders ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Technical Description - Android Embedded SE
On 2012-09-22 08:58, Andreas Jellinghaus wrote: Am 20.09.2012 21:06 schrieb Anders Rundgren anders.rundg...@telia.com mailto:anders.rundg...@telia.com: http://nelenkov.blogspot.se/2012/08/accessing-embedded-secure-element-in.html Very interesting IMHO. Agree, thanks for sharing. According to the author SD-slots are becoming exceptions also for Android so this is probably what most people will be dealing with. I think he is also over optimistic with multi applications on a Java card SE, but we will see. Indeed. I even wonder if the SE needs to host applications at all. IMO, it would be enough if the SE hosts keys and associated attributes while the applications either rather run at OS-level as trusted processes like PIN input etc. or as standard applications. As far as I understand the Wallet is just an Android App that is trusted by the SE. 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. Here is a write-up of a possible ACL-scheme that is intended for the Web and App: http://webpki.org/papers/PKI/pki-webcrypto.pdf Anders The NFC chip should be similar to what can be used with libnfc, so porting all the mifare copy clone and fake tools would be awesome... Andreas Anders ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org mailto:opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Technical Description - Android Embedded SE
2012/9/22 Anders Rundgren anders.rundg...@telia.com On 2012-09-22 08:58, Andreas Jellinghaus wrote: Am 20.09.2012 21:06 schrieb Anders Rundgren anders.rundg...@telia.commailto: anders.rundg...@telia.com: http://nelenkov.blogspot.se/2012/08/accessing-embedded-secure-element-in.html Very interesting IMHO. Agree, thanks for sharing. According to the author SD-slots are becoming exceptions also for Android so this is probably what most people will be dealing with. I think he is also over optimistic with multi applications on a Java card SE, but we will see. Indeed. I even wonder if the SE needs to host applications at all. IMO, it would be enough if the SE hosts keys and associated attributes while the applications either rather run at OS-level as trusted processes like PIN input etc. or as standard applications. As far as I understand the Wallet is just an Android App that is trusted by the SE. well, even if the battery of the mobile phone is empty, the secure element can still be powered by any reader and thus still work. Implementations can or cannot make use of this - if the implementation prefers the user to take the phone out of his bag, unlock it, open some app and make the I approve gesture, then disabling it is a good idea to prevent unauthorized usage. 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. I must admit I don't know how many apps are managed and seperated. given the restricted resources a smart card has, I assume there is a master key that creates contain of specific sizes/dimensions/... and the app is loaded into such a container, limiting it and reserving the unallocated space for further applications/containers? Is there a standard on doing this, or is it all JCOP magic under NDA? 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? Here is a write-up of a possible ACL-scheme that is intended for the Web and App: http://webpki.org/papers/PKI/pki-webcrypto.pdf hmm, that link is configured as download :( a normal link would be easier so chrome users can browse it without a download to the filesystem (and another file kept around in Dowload/ folder forever). I haven't looked into this into very detailed. My new impression is I would only need to use a smart card keycert with one site only - my SSO provider. Thus a plugin for that communication only would work well with me. I use two browsers, thus could have a differnt plugin each time linked to a different identity. Not sure if I wanted to share a card for that purpose, that agains simplifies my requirements I would have for a smart card a lot. Like many people I noticed that people have their mobile phone with them all the time, and notice if they lost it right away. Thus using a mobile phone for authenticating any other device seems to be the right thing to do and works well for many people in practice. Thus using the SE in such a phone can become interesting. Not sure what to do about phone theft though - I really fear putting all the access credentials into one basket (my phone), plus a lot of personal information, so any thief would be able to impersonate me and access my mail, documents, banks, and much more. In summary: my old expectations how to secure communication and use smart cards in them have gone many months ago, now I see the world very differently. My adventures into smart card business also make me wonder if trusting such an industry is a good thing. Andreas Anders The NFC chip should be similar to what can be used with libnfc, so porting all the mifare copy clone and fake tools would be awesome... Andreas Anders ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org mailto: opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Technical Description - Android Embedded SE
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... 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 keycert 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. Not sure what to do about phone theft though - I really fear putting all the access credentials into one basket (my phone), plus a lot of personal information, so any thief would be able to impersonate me and access my mail, documents, banks, and much more. For this I simply use keepass w/ its db synced over dropbox (and backed up offline in multiple places). Obviously a thief wouldn't have my master password, so the access to the db would be useless. In summary: my old expectations how to secure communication and use smart cards in them have gone many months ago, now I see the world very differently. My adventures into smart card business also make me wonder if trusting such an industry is a good thing. Always too many things under NDA or plainly unavailable, too often starting from comm specs... BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Technical Description - Android Embedded SE
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! 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 keycert 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. Not sure what to do about phone theft though - I really fear putting all the access credentials into one basket (my phone), plus a lot of personal information, so any thief would be able to impersonate me and access my mail, documents, banks, and much more. For this I simply use keepass w/ its db synced over dropbox (and backed up offline in multiple places). Obviously a thief wouldn't have my master password, so the access to the db would be useless. In summary: my old expectations how to secure communication and use smart cards in them have gone many months ago, now I see the world very differently. My adventures into smart card business also make me wonder if trusting such an industry is a good thing. Always too many things under NDA or plainly unavailable, too often starting from comm specs... BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Technical Description - Android Embedded SE
http://nelenkov.blogspot.se/2012/08/accessing-embedded-secure-element-in.html Very interesting IMHO. According to the author SD-slots are becoming exceptions also for Android so this is probably what most people will be dealing with. Anders ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
