Active Topics
-
Is there a section to talk about Java ME? Apps, etc. (3)
to General by Kalatti - 14 hrs, 37 mins ago - more...
|
2010-05-24
, 16:59
|
|
Posts: 2 |
Thanked: 1 time |
Joined on Jan 2010
|
#32
|
Hi, I have some questions maybe they have already been answered I shall work though all these threads and pages on the subject I have found.
* What is the best email address (or method of contact) to the Nokia Security team that is working on this ?
* Which product does the team believe this shall be released into, Maemo6 or Meego1 (or both - i.e. FOSDEM was before/around the Meego announcement and I'm working towards Meego to see if some of my requirements can be added to the platform) ?
* The community require to make use of all features of "closed mode" where there is a common goal (for example the purpose of providing rootkit protection for users of alternative kernels but those users are not themselves developers). For this there would need to be the ability to set and store a few additional cryptographic keys provided by the user (presumably in "open mode" to do that), the verification code (in NOLO) needs to optimally select the correct key to perform verification with for the image it is loading (verfiying each key found in a locally stored repoistory until you get a match maybe too slow at bootup!) and there would need to be at least one additional mode to mean "any verifed kernel image". Where "closed mode" (aka "vendor mode") would only boot images that verfiied with a vendors (hidden/closed/secret/immutable to community) key. These would be features of NOLO, since the trusted execution needs to start from there, this means Nokia would need to provide details/documentation of how that works to the community. Alternatively the community die hards would need to seek to replace NOLO (because the feature of Trusted Execution would not be available to them otherwise).
* There is a specific Threat Model to mobile devices that the current Maemo5 (from what I can see) does not seem to address. That is providing fine granularity over the protections and lockouts of the device. To address this the device need to provide some basic assurances:
** Any keys that are changed, there must be assurance the old key is destroyed (this is not true of N900, and a special problem for flash devices that level-wear). If you are going to move the flash storage block where the security key data WAS stored, then you must erase/rewrite/destory the old copy of the key (once you are happy you committed the new copy sucessfully). So key scrubbing for this one.
** It is known that the Modem unit inside the phone has storage available inside it, are the methods for accessing and using that storage available to the community ?
** Users must be able to make their device worthless when stolen, both in terms of data content and in terms of not allowing a thief to reflash the phone to resell it (they are flagship products). Also included in this is the ability to lockdown the entire device hardware (i.e. requires unlock code on power up) when a Mobile Network Operator barrs the SIM from registering on the network. All this when combined with handset to SIM card locking (common in many other Nokia products) provides a pretty watertight way to an owner making theft ineffective.
** Bulk data security is already well understood and would be the next features to be added after the groundwork (listed above) is in place. This is not a priority while the above basic stuff still needs attention.
As for the new APIs added by the Maemo Security team (as outlined at FOSDEM) it all sounds very good for other stake holders (who are not actually the phone end-users). I can only presume that your bulk buying customers (i.e. Mobile Network Operators) are pushing for these features in order to purchase the next model. I can also understand the commercial application interest too in the APIs for licensing/DRM and such so from that standpoint the higher layer parts the FOSDEM talk all make sense.
So whatever is implemented could the mechanisms be just as available for use by the community as they are for Nokia, MNOs and DRM application writers ? This starts by allowing a community kernel to be signed by a community key and for the end-user to have peace of mind that trusted execution is still at work. Rootkits would be bad news for the platform.
Last edited by dlmiles; 2010-05-25 at 16:02.
* What is the best email address (or method of contact) to the Nokia Security team that is working on this ?
* Which product does the team believe this shall be released into, Maemo6 or Meego1 (or both - i.e. FOSDEM was before/around the Meego announcement and I'm working towards Meego to see if some of my requirements can be added to the platform) ?
* The community require to make use of all features of "closed mode" where there is a common goal (for example the purpose of providing rootkit protection for users of alternative kernels but those users are not themselves developers). For this there would need to be the ability to set and store a few additional cryptographic keys provided by the user (presumably in "open mode" to do that), the verification code (in NOLO) needs to optimally select the correct key to perform verification with for the image it is loading (verfiying each key found in a locally stored repoistory until you get a match maybe too slow at bootup!) and there would need to be at least one additional mode to mean "any verifed kernel image". Where "closed mode" (aka "vendor mode") would only boot images that verfiied with a vendors (hidden/closed/secret/immutable to community) key. These would be features of NOLO, since the trusted execution needs to start from there, this means Nokia would need to provide details/documentation of how that works to the community. Alternatively the community die hards would need to seek to replace NOLO (because the feature of Trusted Execution would not be available to them otherwise).
* There is a specific Threat Model to mobile devices that the current Maemo5 (from what I can see) does not seem to address. That is providing fine granularity over the protections and lockouts of the device. To address this the device need to provide some basic assurances:
** Any keys that are changed, there must be assurance the old key is destroyed (this is not true of N900, and a special problem for flash devices that level-wear). If you are going to move the flash storage block where the security key data WAS stored, then you must erase/rewrite/destory the old copy of the key (once you are happy you committed the new copy sucessfully). So key scrubbing for this one.
** It is known that the Modem unit inside the phone has storage available inside it, are the methods for accessing and using that storage available to the community ?
** Users must be able to make their device worthless when stolen, both in terms of data content and in terms of not allowing a thief to reflash the phone to resell it (they are flagship products). Also included in this is the ability to lockdown the entire device hardware (i.e. requires unlock code on power up) when a Mobile Network Operator barrs the SIM from registering on the network. All this when combined with handset to SIM card locking (common in many other Nokia products) provides a pretty watertight way to an owner making theft ineffective.
** Bulk data security is already well understood and would be the next features to be added after the groundwork (listed above) is in place. This is not a priority while the above basic stuff still needs attention.
As for the new APIs added by the Maemo Security team (as outlined at FOSDEM) it all sounds very good for other stake holders (who are not actually the phone end-users). I can only presume that your bulk buying customers (i.e. Mobile Network Operators) are pushing for these features in order to purchase the next model. I can also understand the commercial application interest too in the APIs for licensing/DRM and such so from that standpoint the higher layer parts the FOSDEM talk all make sense.
So whatever is implemented could the mechanisms be just as available for use by the community as they are for Nokia, MNOs and DRM application writers ? This starts by allowing a community kernel to be signed by a community key and for the end-user to have peace of mind that trusted execution is still at work. Rootkits would be bad news for the platform.
Last edited by dlmiles; 2010-05-25 at 16:02.
| The Following User Says Thank You to dlmiles For This Useful Post: | ||
 |
|
2010-05-25
, 04:20
|
|
Posts: 3,105 |
Thanked: 11,088 times |
Joined on Jul 2007
@ Mountain View (CA, USA)
|
#33
|
The meego-dev mailing list is probably a more appropriate place to reach the developers and have a technical discussion now that MeeGo is the primary target distribution for this security framework.
If you want to contact the developers http://meego.gitorious.org/meego-platform-security gives you a direct path.
If you want to contact the developers http://meego.gitorious.org/meego-platform-security gives you a direct path.
Are they willing to merge the idea? the implementation? It could be a huge cost if upstream requires backwards incompatible changes to be accepted. It is also a huge cost to Nokia and the users to always be running a fork.
Are desktop distributions interested in using the security model? Is there interest or consensus from other security implementers (app armor, selinux, etc?
770, n810, n900, Ideapad S10-3t
TheOneRing, DialCentral, Gonvert, Quicknote, Multilist, ejpi, nQa, Waters of Shiloah
Programming Blog