[patch 0/6] [RFC] Add MMC Password Protection (lock/unlock) support V6

[patch 0/6] [RFC] Add MMC Password Protection (lock/unlock) support V6

[Anderson Briglia]

Hi all,

New in this version:

- MMC_CAP_BYTEBLOCK capability support added.
- Spin lock added to protect data into mmc_lock_unlock function.
- Specific OMAP platform adjustment regarding DMA transfers.
- Some minor fixes pointed by Pierre Ossman on V5 version.

This series of patches add support for MultiMediaCard (MMC) password
protection, as described in the MMC Specification v4.1. This feature is
supported by all compliant MMC cards, and used by some devices such as
Symbian OS cell phones to optionally protect MMC cards with a password.

By default, a MMC card with no password assigned is always in "unlocked"
state. After password assignment, in the next power cycle the card
switches to a "locked" state where only the "basic" and "lock card"
command classes are accepted by the card. Only after unlocking it with
the correct password the card can be normally used for operations like
block I/O.

Password management and caching is done through the "Kernel Key
Retention Service" mechanism and the sysfs filesystem. A new sysfs
attribute was added to the MMC driver for unlocking the card, assigning
a password to an unlocked card, change a card's password, remove the
password and check locked/unlocked status.

A sample text-mode reference UI written in shell script (using the
keyctl command from the keyutils package), can be found at:

http://www.indt.org.br/10le/mmc_pwd/mmc_reference_ui-20060130.tar.bz2


TODO:

- Ongoing: Extend the MMC PWD Scheme to SD Cards.

- Password caching: when inserting a locked card, the driver should try
   to unlock it with the currently stored password (if any), and if it
   fails, revoke the key containing it and fallback to the normal "no
   password present" situation.

Known Issue:

- Some cards have an incorrect behaviour (hardware bug?) regarding
   password acceptance: if an affected card has password <pwd>, it
   accepts <pwd><xxx> as the correct password too, where <xxx> is any
   sequence of characters, of any length. In other words, on these cards
   only the first <password length> bytes need to match the correct
   password.


Comments and suggestions are always welcome.

--
Anderson Briglia,
Carlos Eduardo Aguiar
Embedded Linux Lab - 10LE
Nokia Institute of Technology - INdT
Manaus - Brazil
--

Re: [patch 0/6] [RFC] Add MMC Password Protection (lock/unlock) support V6

[David Brownell]

On Friday 17 November 2006 4:58 am, Anderson Briglia wrote:

> - Password caching: when inserting a locked card, the driver should try
>    to unlock it with the currently stored password (if any), and if it
>    fails, revoke the key containing it and fallback to the normal "no
>    password present" situation.

Is there some reason why the key isn't associated with the MMC/SD card
identifier(s)?  It should be practical to swap several cards in/out
without the kernel _needing_ to discard their keys.  What you're saying
is that you'll cache only one key at a time, and that it won't have
anything associating it with a particular card.  That's not at all how
the key retention service is designed to work...


> - Some cards have an incorrect behaviour (hardware bug?) regarding
>    password acceptance: if an affected card has password <pwd>, it
>    accepts <pwd><xxx> as the correct password too, where <xxx> is any
>    sequence of characters, of any length. In other words, on these cards
>    only the first <password length> bytes need to match the correct
>    password.

I thought the MMC vendors expected to see the actual user-typed
password get SHA1-hashed into a value which would take up the whole
buffer?  In general that's a good idea, since it promotes use of
longer passphrases (more information) over short ones (easy2crack).

Plus, such hashing would prevent this issue ... if vendor tests are
done with hashed passphrases, that would explain why this class of
hardware issue got past design validation.

- Dave

Re: [patch 0/6] [RFC] Add MMC Password Protection (lock/unlock) support V6

[Pierre Ossman]

David Brownell wrote:
> I thought the MMC vendors expected to see the actual user-typed
> password get SHA1-hashed into a value which would take up the whole
> buffer?  In general that's a good idea, since it promotes use of
> longer passphrases (more information) over short ones (easy2crack).
>   

This sounds like policy though, so it is something user space should
concern itself with. We should just provide the infrastructure.

Rgds

-- 
     -- Pierre Ossman

  Linux kernel, MMC maintainer        http://www.kernel.org
  PulseAudio, core developer          http://pulseaudio.org
  rdesktop, core developer          http://www.rdesktop.org

Re: [patch 0/6] [RFC] Add MMC Password Protection (lock/unlock) support V6

[David Brownell]

On Saturday 18 November 2006 1:42 pm, Pierre Ossman wrote:
> David Brownell wrote:
> > I thought the MMC vendors expected to see the actual user-typed
> > password get SHA1-hashed into a value which would take up the whole
> > buffer?  In general that's a good idea, since it promotes use of
> > longer passphrases (more information) over short ones (easy2crack).
> >   
> 
> This sounds like policy though, so it is something user space should
> concern itself with. We should just provide the infrastructure.

The kernel shouldn't hash, right.  But the userspace toos
probably should be doing that ... they're the other part of
the infrastructure. :)

- Dave

Re: [patch 0/6] [RFC] Add MMC Password Protection (lock/unlock) support V6

[Anderson Lizardo]

Hi David,

On 11/18/06, David Brownell <david-b@pacbell.net> wrote:
> On Saturday 18 November 2006 1:42 pm, Pierre Ossman wrote:
> > David Brownell wrote:
> > > I thought the MMC vendors expected to see the actual user-typed
> > > password get SHA1-hashed into a value which would take up the whole
> > > buffer?  In general that's a good idea, since it promotes use of
> > > longer passphrases (more information) over short ones (easy2crack).
> > >
> >
> > This sounds like policy though, so it is something user space should
> > concern itself with. We should just provide the infrastructure.
>
> The kernel shouldn't hash, right.  But the userspace toos
> probably should be doing that ... they're the other part of
> the infrastructure. :)

Interesting idea, indeed. We'll implement this in our reference UI
(which currently is just a bunch of shell scripts) so we can test the
feasibility of this approach. Additionally, I think it's a good idea
to investigate how other vendors currently support password protection
on their products (for now I've just seen Nokia cellphones with such
support, maybe PDAs or other mobile devices support this?), so we can
have compatible policies, allowing to lock/unlock cards across
devices.

Anyway, I also agree this is out of scope of the kernel support, but
still it's very important for a complete support.

Regards,
-- 
Anderson Lizardo
Open Source Mobile Research Center - OSMRC
Nokia Institute of Technology - INdT
Manaus - Brazil