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 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. 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 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. 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
