[Dev] usb-manager: set correct usb gadget attributes

Tomasz Swierczek t.swierczek at samsung.com
Wed Dec 18 10:48:06 GMT 2013

Dear All,

I read what the problem is about and want to share some ideas/thoughts on

We could - like proposed in the original problem description - create a
special partition for storing such kind of data. In fact, we already have
some RO partitions that keeps the kernel and its modules, plus some other,
fragile system elements (libraries, data, configuration, etc.).

The problem with such thing, is that of course root can access the RO
partition, (re)mount it possibly - so with rooted device this could be

Now, we could fight this - by implementing some integrity measurement system
(like IMA/EVM). But, for this to be really secure, we would need some key
storage in hardware (TPM/sth similar). For example - we could sign the
fragile data with a private key never stored on the device, and keep only
the device-unique public key for checking the signing on the device. The
kernel could load such key from the device hardware/secure bootloader. Of
course, secure boot should be enabled to make this work, because the kernel
should also be signed (so that no one will load kernel that bypasses the
integrity checks).

>From our perspective, what I think we should do is to keep the fragile
information on RO partition and implement some integrity measurement system
(like IMA/EVM in Linux kernel) that will guard integrity of such fragile
data and hope that device manufacturers will provide secure boot AND TPM so
that no one will be able to bypass these integrity checks. IMA/EVM can be
easily enabled in kernel so I don't think this is a big problem then. It's
up to device manufacturers. We - as platform developers - can provide means
to make this solution secure, they need to use it.

Best Regards,

Tomasz Swierczek

-----Original Message-----
From: Krzysztof Opasiak [mailto:k.opasiak at samsung.com] 
Sent: 18 grudnia 2013 10:59
To: 'Stoppa, Igor'; Tomasz Swierczek
Cc: 'Yang Chengwei'; 'Taeyoung Kim'; 'Krogerus, Heikki';
dev at lists.tizen.org; 'Brad T Peters'
Subject: RE: [Dev] usb-manager: set correct usb gadget attributes

+ Tomasz Swierczek

Dear Security team,
could you support us in discussion about the topic from the bottom of

Hi Igor,

> -----Original Message-----
> From: Stoppa, Igor [mailto:igor.stoppa at intel.com]
> Sent: Monday, December 16, 2013 5:31 PM
> To: Krzysztof Opasiak
> Cc: Yang Chengwei; Taeyoung Kim; Krogerus, Heikki; 
> dev at lists.tizen.org; Brad T Peters
> Subject: Re: [Dev] usb-manager: set correct usb gadget attributes
> Hello Krzysztof,
> apologies for the late reply, somehow I missed your last mail.
> Please find my reply inlined below.
> On 27 November 2013 10:57, Krzysztof Opasiak <k.opasiak at samsung.com> 
> wrote:
> 	Hi Igor,
> 	> -----Original Message-----
> 	> From: Stoppa, Igor [mailto:igor.stoppa at intel.com]
> 	> Sent: Friday, November 22, 2013 3:36 PM
> 	> To: Krzysztof Opasiak
> 	> Cc: Yang Chengwei; Taeyoung Kim; Krogerus, Heikki;
> 	> dev at lists.tizen.org; Brad T Peters
> 	> Subject: Re: [Dev] usb-manager: set correct usb gadget attributes
> 	>
> 	> (+Brad)
> 	>
> 	> Hi Krzysztof,
> 	>
> 	>
> 	> On 22 November 2013 14:15, Krzysztof Opasiak
> 	> <k.opasiak at samsung.com> wrote:
> 	>
> 	> [snip]
> 	>
> 	>       Let me summarize and please correct me if I'm wrong.
> We have
> 	> a PC in
> 	>       host mode and multiple devices with tizen in USB
> device mode.
> 	>
> 	>
> 	> Typically.
> 	> However from time to time these devices will be:
> 	>
> 	> a) re-flashed to upgrade to a newer tizen build
> 	Flash is done using ttyXACM not usb raw transport directly so there 
> is
> 	no problem to address each target directly. When you connect two 
> targets
> 	you will get ttyACM0 and ttyACM1 so the only thing we have to do is 
> to
> 	write flash tool correctly so you can set which pseudo device you 
> would
> 	like to use for flashing.
> that's good - the only constraint here is that the id must be 
> consistent with both:
> 1) what is assigned to the device in the factory, if available (but in 
> commercial devices, it will be available)
> 2) what is reported by the device when in other modes but this is 
> really a requirement for the other modes, provided that
> 1) is satisfied.

But why would you like to use the ID for flashing?

In my opinion USB topology is better to discover which USB device we are
talking to. Let's assume that you have 3 different targets. You would like
to flash them all but each with different image. It's better to know which
cable is ttyACM1, ttyACM2 etc. than know the 3 long id's of each device. The
topology could be constant. You can have some stickers on USB connectors and
connect "connector 1" to target XYZ and then you are sure that you are
flashing this particular device. If you would like to do that same with ID's
you should compare the longs targets ID's instead of simply connecting the
device to correct connector.

> 	> b) automatically detached and re-attached to perform some task in
> 	> scenario
> 	> more similar to normal usage (iow no cables)
> 	>
> 	This scenario could be done using some extension to sdb.
> Tizen will use
> 	ConfigFS, we plan to provide API for usb gadgets management.
> One of the
> 	benefits of ConfigFS is that we can simply disable and enable gadget

> in
> 	a runtime when device is plugged in. So This scenario could be 
> realized
> 	if sdb will be able to use this API and provide some extension to do
> 	this. For example sdb could simply execute
> 	$ gt disable sdb_gadget; sleep 5; gt enable sdb_gadget
> I don't think that's possible.
> AFAIK there is no support in the USB standard for electrically 
> disconnect
> a gadget device that is connected to a certain port.
> Sure, it can be disconnected at logical level, charging can also be 
> refused, but the gadget will still be aware of the master.
> I'm using a USB gadget that acts as real electrical switch [1]

Such electrical switch is not necessary. In Tizen reference Kernel we have
ConfigFS and we will use it for gadget composition. There is a "file" called
UDC. So doing simply:

$ echo "" > UDC

Disables gadget and

$ echo "udc-name" > UDC

Enables gadget. Those commands are enough to do support your scenario.
For host it's similar to physical detachment of device.

-------------------------TOPIC FOR SECURITY TEAM----------------

Please read the previous discussion below and share your opinion about
storing device specific data like SN's, MAC address and some calibration

> 	I have spoken with my colleagues and they told me that this problem 
> is
> 	not only in usb. There are other parts of system which needs unique
> 	numbers. Maybe there should be general solution made for this 
> problem?
> 	The solution could be similar to this which you described, a special
> 	partition flashed in factory, but there are some problems.
> For example
> 	we should ensure that user will not be able to change the content of
> 	this partition even with rooted device.
> Indeed.
> Pretty much anything that needs to have a MAC address has similar 
> behaviour
> and needs.
> The typical hackish solution is to generate a random MAC at first boot 
> and store it somewhere.
> However usually this won't survive a reflash, because the "somewhere" 
> is located on the file system, rather than in a protected area.
> Wrt security, I see only 2 options:
> a) somehow the system provides some sort of secure storage that can be 
> accessed only through a chain of trust that even gaining root cannot 
> spoof.
> A bit like DRM, so maybe that infrastructure could be leveraged also 
> for other purposes.
> b) root is demoted and is no different from a somehow privileged user.
> But it means that only OEM-signed kernels will be allowed, if the OEM 
> wishes so.
> Btw, this was the security model for the Nokia N9.
> And even in case users are allowed to gain full access, it should be 
> somehow stored permanently that factory data was overwritten.
> Then comes yet another category of data that fits in the same
> pattern: calibration data.
> Typically this refers to radios.
> There might be even legal implications in allowing users to freely 
> change how the radios behave.
> But all of this would require someone with security background to 
> comment.
> I'm not a security expert.

I'm also and that's why I pleased security Team to join the discussion.


Krzysztof Opasiak
Samsung R&D Institute Poland
Samsung Electronics

More information about the Dev mailing list