Well. I really appreciate your information about HW token, that's good 
information to educate other people. And I also do try to learn some new things 
from it, even we will use that on special HW platform soon.
But again HW token is a small picture in product security, Ryan definitely will 
lead team to figure big picture and enhance lots of thing, but for HW token, 
that's small part of it.
Beyond this discussion, let's do discuss more proposal or solutions to enhance 
MeeGo from product security perspective and defense in depth.
Appreciate your discussion and argument!

Thanks & Regards
Xiaoning


-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of 
Sebastian Lauwers
Sent: Tuesday, April 13, 2010 8:03 PM
To: Li, Xiaoning
Cc: Ware, Ryan R; MeeGo Dev List
Subject: Re: [MeeGo-dev] MeeGo Security

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

Reply via email to