On Wed, Apr 14, 2010 at 12:39 PM, Li, Xiaoning <[email protected]> wrote: > But I am interested in what you talking here. > Beyond the HW tokes ( that's depended on HW platform, if SW stack exists, > possibly team need to port it to MeeGo),
Software tokens to generate OTPs are inherently insecure. They can be stolen as soon as the software stack is compromised, and wouldn't prevent an attack as thorough as the one the Apache organisation has seen. It would only require one compromised application to get through QA and installed on a few devices, and the attackers would get access to your key. This is why it is important to have a hardware token. It is possible to implement a hybrid between these two. If I understand you correctly, you are not in favour of hardware tokens that would generate OTPs [1]. Another option, rather than a full software solution, would be to have a hardware component inside a MeeGo device that would help to store the credentials, which would then be subsequently used to generate an OTP. As I said, this is possible. Some smartcard vendors provide smartcards in the form of microSD chips, and the solution works (I have one in my N900 at the moment, and can, for example, query the smartcard ATR using closed-source drivers and an open source and standard software stack [2]). However, this does not prevent the issue of a malicious piece of software being pushed through, and then delivered to the devices. Once the software is activated, it could query the smartcard inside the N900, and forward the OTPs to the attacker. This is why a standalone hardware token is preferable. > why you don't think "both Nokia and Intel's expertise in securing systems > will be invaluable" > What kinds of expertise we need to secure system by your suggestion? Simple expertise that is already being used, and I'm sure Niels can provide more information with this. The expertise would be demonstrated when deploying the infrastructure, by making sound decisions with regards to user-password and user-data being encrypted, and how this encryption is managed -- by using random salts [3]. Also, the way the infrastructure is laid out (separate accounts for separate systems, separate systems for separate services,), sandboxed and audited. > HW can't handle most attacking in real world, any recommendation for software > or system perspective? Hardware tokens and security implementations are the only thing that can survive against most attacks. Software storage and solutions are utterly useless, especially when your keys (or OTP seed) is stored on a device as volatile and vulnerable as a mobile phone or laptop. Any security can be broken. I could go on and rant about how even with hardware tokens generating an OTP that unlocks a smartcard which contains the certificates used to encrypt a connection and authenticate a user to a remote server can be compromised. It takes a ludicrous amount of effort for the attacker, but anything can be broken. At some point we just need to be real and understand what we are trying to protect, and how much paranoia is required. To be fair, I believe that in MeeGo's situation, this thread clearly demonstrates that the paranoia is way too high. We are not an international bank or government trying to protect highly sensitive data. This is an Open Source project, and the most sensitive thing we have are the contributors' usernames and passwords. I'm pretty sure the bugzilla database is being backed up regularly, same for the wiki and forum. As for Nokia and Intel's systems, they are firewalled, VPN'd and utterly not our concern. In other words: We can all go back to sleep. [1]: http://en.wikipedia.org/wiki/One-time_password [2]: http://pcsclite.alioth.debian.org/ [3]: http://en.wikipedia.org/wiki/Salt_%28cryptography%29 -- question = ( to ) ? be : ! be; -- Wm. Shakespeare _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
