+Casey @Casey: while discussing about USB IDs popped up the more generic topic of how to deal w/ device specific strings, such as MAC addresses and calibration data.
You can find the relevant parts of the discussion below. --- cheers, igor On 18 December 2013 12:48, Tomasz Swierczek <[email protected]> wrote: > 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: > [snip] -------------------------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 > > > > > > -- cheers, igor
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
