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 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. > 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 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. :) > 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 them, if you do it manually and not well trained and with little know-how. > 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... > hmm, maybe I'm mixing openid, oauth and other stuff here? not an expert on these technologies. >> 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...). > so your JCOP cards have the public known dummy key on them? thats nice for test cards, but some vendors sell them with real keys I think, and then it is a large hassle to use them / negotiate re-keying first etc. I think some people are paranoid to require a full tracking from chip production to end user, with secure keys used during the whole chain, so each entity has to negotiate keys with the previous and next entities and rekey the SE when receiving and/or before handing it to the next entity. I wonder why there is no counter for authenticating to the card, that never decreases or overflows? if you saw any card with the counter at 0, you would know that noone ever has changed anything, as that would require an authentication with fab keys first, and would increase the counter, and thus the fab key could be public and everyone could forward cards without re-keying. but if people want to be flexible and buy from different source and via different routes, then they again like this chain with changing the card in each step, as they can hide how they got the SE and can make it look like every other SE they deliver. guess that is a very strong motivation to have a complex system. Regards, 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
