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 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 thought there was some discussion about it - v1 too complex, not much agreement on v2 or so? > > 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. > well, unless it can be sniffed or brute forced... but this is a sound trust decission - we need to be aware of the attack vectors though. > 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... > 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, it seems to change now with many the consolidation phase - unless you need to be compatible to something old, there are few products left. outside of card standards enforced by the customers - telco for sim cards and visa/master card for credit cards - 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. And JCOP again is a prime example of a NDA thing, not a standard, right? or did it improve? Andreas > 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
