Dear All, I read what the problem is about and want to share some ideas/thoughts on it.
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 modified. 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:[email protected]] Sent: 18 grudnia 2013 10:59 To: 'Stoppa, Igor'; Tomasz Swierczek Cc: 'Yang Chengwei'; 'Taeyoung Kim'; 'Krogerus, Heikki'; [email protected]; '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 message? Hi Igor, > -----Original Message----- > From: Stoppa, Igor [mailto:[email protected]] > Sent: Monday, December 16, 2013 5:31 PM > To: Krzysztof Opasiak > Cc: Yang Chengwei; Taeyoung Kim; Krogerus, Heikki; > [email protected]; 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 <[email protected]> > wrote: > > > Hi Igor, > > > > -----Original Message----- > > From: Stoppa, Igor [mailto:[email protected]] > > > Sent: Friday, November 22, 2013 3:36 PM > > To: Krzysztof Opasiak > > Cc: Yang Chengwei; Taeyoung Kim; Krogerus, Heikki; > > > [email protected]; Brad T Peters > > Subject: Re: [Dev] usb-manager: set correct usb gadget attributes > > > > > (+Brad) > > > > Hi Krzysztof, > > > > > > On 22 November 2013 14:15, Krzysztof Opasiak > > <[email protected]> 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 a > > 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 data. > > 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. -- BR's Krzysztof Opasiak Samsung R&D Institute Poland Samsung Electronics _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
