Editing Talk:Maemo security

Warning: You are not logged in. Your IP address will be recorded in this page's edit history.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.

Learn more about Contributing to the wiki.

A wiki is probably the best tool we have but it's not perfect.
To make it work better please sign your comments and try to maintain some structure.

Putting three ~ and a : at the start of a new comment sounds sane if you have an account; otherwise some identifier would be polite.

Suggested questions:

===What is "Open Mode" and can it be revoked remotely?===
[[User:lbt|lbt]] Essentially can Nokia reach out the the 2nd stage bootloader and  tell it to stop running unsigned kernels.
Maybe this should be 2 questions.

--[[User:elena_r|elena_r]] 08:37, 28 October 2009 (UTC):Short answer: "Open mode" allows for a user/developer to have their own security policy on a device. This means that a user/developer can change the kernel and the important system components in the way he wants/needs. This mode can't be revoked remotely.

More detailed answer: Let me explain the modes a bit more that there are no confusions. Sorry, if I would be too academic or a bit too high-level, but it is the best way to explain things at the moment, as soon as we can't fully share the details now (work is still in progress).

About the first mode (it got the name "close mode", but it sounds too strong, so let's call it "normal mode"at the moment, before we have the final names): The device is called to be in the "normal mode", if it has booted the Nokia signed SW Image. This includes the kernel, rootfs, and important system components, which are part of our Trusted Computing Base. The examples of such components are drivers, applications like Application manager (input gate for the SW on the platform) and many others.

If any of such components is modified (not via system update), the device is in the "open mode". The checks for the components signature are done during the boot process (see presentation), so the current assumption that in order to change the mode, the reboot is needed. Moreover, in order to get back to the "normal mode" from the "open mode", one has to get all components back that the Nokia signature check is successful. The details of the procedure should be available later.

===Can open applications use the DRM encryption mechanisms in the Open and Closed modes?===
[[User:lbt|lbt]] I can see that this could be useful. Maybe.

--[[User:elena_r|elena_r]] 08:52, 28 October 2009 (UTC):Let me explain about the purpose of the DRM: The DRM should be used to protect the commercial content (such as applications, music) from unauthorized copy protection (the content, which would be distributed via Ovi store). Applications have another possibility to encrypt the data by using the APIs from the "Protected Storage" component, which was introduced during the presentation. They should be quite easy to use and give a lot of flexibility for the data encryption. The Protected storage's APIs can be used in both modes, but the encryption won't work, when you switch from one mode to another (for example if application uses the APIs to encrypt the data in the "normal mode", it won't be able to decrypt it in the "open mode", and vise verse).

===Is there any GPLv3 software impacted?===
[[User:lbt|lbt]] this is @ community: Please have a license discussion somewhere and let us know when you have consensus.

[[User:lbt|lbt]] What is Nokias position? Peter made a statement at the talk - can someone transcribe it and/or get Nokia to clarify.

[[User:keesj|keesj]] During the Q&A of the second Maemo 6 security presentation at the the Maemo 2009 summit it was made clear GPLv3 component will not be accepted in the platform.

===What exactly is available to the end user?===

* storage encryption ?
* PIM data encryption ?
* encrypted/signed communications (phone, sms/mms, mails, IM) ?

--[[User:elena_r|elena_r]] 12:45, 28 October 2009 (UTC): If I understood the question correctly, it is about the benefits for the user that the Security FW provides.

Here are the examples of the benefits:

1. Security FW allows us to introduce new business models (based on the DRM), which hopefully will bring much more good applications to the end users.
2. Security FW provides the tools for the applications, which can be used to make the user's data to be more secure (again, the example with the protected storage, which can be used to encrypt all your messages and store them on the device in the encrypted form (if application wishes to do so)).

One can find out more use cases, but in short, the Security FW is an enabler for many good future application and use cases(probably some we even can't see now). So, it is up to developer's to use this advantage and develop cool applications in new domains, where the security of an application (or its data) is important.

=== How does closed mode affect on-device debugging? ===

For example, will ptrace(2) still work (eg gdb, strace & ltrace)?  Will we be able to produce code dumps?

--[[User:elena_r|elena_r]] 09:00, 28 October 2009 (UTC):For security reasons the idea is that a developer should be able to debug its own code (application), but should not be able to assign a debugger to another process. Of course, the memory dumps, for example of the kernel memory, should be restricted, too. This is valid for the "normal mode". For the "open mode" one should be able to do everything.

===Will DRM-free data and DRM-free applications be accessible from both modes once they're installed/created in either of the two modes?===

E.g.: I start in DRM-mode, install DRM-free applications from Extras, take 3 pictures, add some contacts. Then I switch to DRM-free mode: Will I be able to run the applications installed in DRM-free mode, view and edit my contacts and view and edit my own pictures? (And the other way round, of course, starting from DRM-free mode and switching to DRM afterwards.)

--[[User:elena_r|elena_r]] 10:19, 28 October 2009 (UTC):I will answer based on the example given above. After switching to the DRM-free mode, you should be able to use your application, access your pictures, contacts and so on (of course, if you didn't reflash the whole rootfs (in this case, you will probably need to reinstall the application), or if the application doesn't use the protected storage to encrypt, for example,  the images(in this case, it won't be able to decrypt it)). The other way round is a bit more specific. As I answered above, in order to return to the "normal mode" (or "DRM mode"), one need to return all components to their initial state. The simplest way to do it is to reflash the whole Nokia signed SW image (kernel, rootfs, and so on) back, but in this case, the data on the rootfs is lost (and your application needs to be installed again). I can't say now that will be the final way to move back to the "normal mode", because this is still work in progress.

[[User:keesj|keesj]] Not having contact data protected sounds like a failure to provide useful  security features so I expect the contact data to be protected. If this is the case it should not be possible to view/edit the contact in open mode.

===What is open mode good for at all?===

Provided you don't consume digitally restricted media and don't purchase applications that in any way rely on DRM: You don't need DRM-mode then, but on the other hand why would you want DRM-free mode? What is it you cannot do in DRM-mode in such a scenario?  Use case?

--[[User:elena_r|elena_r]] 10:03, 28 October 2009 (UTC): The typical use case for the "open mode" is that a user wants to define its own security policy, install its own system components, change/extend the kernel and so on. The change of the policy allows you to define the trust on each SW source, for example, you can add your own source of SW and allow it to grant an access to all protected resources (of course, the DRM would be disabled, when you switch to the "open mode"). Low-level platform development is also possible only in the "open mode".

===What is ARM's TrustZone?===
The official ARM TrustZone page:
http://www.arm.com/products/security/trustzone/index.html

===Can the Trusted Execution Environment (TrEE) be used as a kill switch for the device even if it runs in open mode?===

--[[User:elena_r|elena_r]] 09:04, 28 October 2009 (UTC): No, no worries.

===Will a SIM-locked device with a contract become unlocked at the end of the contract?===
[[User:lbt|lbt]] It seems very reasonable to allow the phone to be locked for the duration if that is part of the carrier's contract. After that it should be able to access 'open' mode. Will this be possible? How?

[[User:corsac|Corsac]]: In France for example, it's free (and mandatory) for carriers to accept sim-unlock after 6 months. It may be done before with some fee.

--[[User:elena_r|elena_r]] 09:03, 28 October 2009 (UTC): From our side, it could be possible, but it will be up to your contract with the operator and the local legislation in your country.

===Would Nokia be prepared to have Bruce Schneier and co review the security architecture?===
[[User:lbt|lbt]] a review by a respected external expert like Bruce would be very beneficial to both parties.

--[[User:elena_r|elena_r]] 09:09, 28 October 2009 (UTC): We would be very glad if smbd like Bruce can review our technology :-)
I am, personally, would be very happy to meet him and discuss the security architecture, because the first book I read about security was his famous "Applied cryptography" (I was still in the school at that time), but I am not sure if he is interested in things like this now :-)

=== Will a TPM chip be added? ===

r-r: Could it serve other security purpose then in Open mode?
[[User:corsac|Corsac]]: afaik, TPM is x86 only. But that's the purpose of ARM TrustZone. And we already asked the question, see above.

--[[User:elena_r|elena_r]] 12:47, 28 October 2009 (UTC): As was presented, we have a TrEE (based on the OMAP3), which we are using now.

=== How are important upgrades handled? ===

r-r: Do they require to sign a whole new system image?

--[[User:elena_r|elena_r]] 09:52, 28 October 2009 (UTC):Security FW doesn't put any limitations on how the system SW updates are delivered. It is up to the people, who is doing this, to decide in which way they would like to provide the upgrades.

== Maintaining the discussion ==

On the [http://talk.maemo.org/showthread.php?p=344427#post344427 talk.maemo.org thread], I suggest that end-users are kept at arms' length from this page and we use it as a proper communication mechanism between the community and Elena et al. --[[User:jaffa|Jaffa]] 10:43, 13 October 2009 (UTC)

More discussion in the [http://mg.pov.lt/maemo-irclog/%23maemo.2009-10-11.log.html#t2009-10-11T12:50:36 #maemo chat] which was going on concurrently with the talk and a [http://www.flickr.com/photos/30863507@N02/4007518495/ few] [http://www.flickr.com/photos/30863507@N02/4008286892/ flickr] [http://www.flickr.com/photos/30863507@N02/4007522767/ photos]. --[[User:jaffa|Jaffa]] 11:20, 13 October 2009 (UTC)

==Proposed Structure==

===User FAQ===
Community answers to common FAQs based on the technical answers below
* Can I switch modes

===Security Functionality (What can be done)===
* Privilege
* DRM

===Security Framework and Flow (How is it done)===
* boot
** bootROM
** Loader
*** simlock issues?
** kernel

* Runtime
** Privilege Management
*** Ovi/Maemo
** Encryption

===Interoperability===
* Key backup/transfer

===Customisation (Eg Enterprise, Partner)===
* ??

== protected mode hacking ==

If signed kernel will had vulnerability, can it (legally) used by user for escalating his own rights on his own cellphone in protected mode? Will nokia charge such user (or user, publishing a way to hack official kernel) with legal pursuit? #![[Special:Contributions/80.249.182.252|80.249.182.252]] 15:23, 11 February 2010 (UTC)

== SIM locking rationale ==

Keeping the user away from DRMed multimedia content in open mode is a defensible proposition. But what is the rationale for prohibiting open mode on SIM-locked phones? You must know that the vast majority of users will have SIM-locked phones. Advertising Maemo as an open platform when most users will not be able to take advantage of that openness is disingenuous.

To be honest, I have the distinct impression that the SIM-locking restriction is designed to appease carriers who are accustomed to installing sub-optimal firmware that optimizes carrier revenue not user experience. With that restriction in place, there is little reason for users who buy SIM-locked phones to choose Maemo over any other platform.

Please note that all contributions to maemo.org wiki may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see maemo.org wiki:Copyrights for details). Do not submit copyrighted work without permission!

Summary:

Cancel | Editing help (opens in new window)

Retrieved from "http://wiki.maemo.org/Talk:Maemo_security"

Personal tools

Navigation

Views

Editing Talk:Maemo security

@@ Line 47: / Line 47: @@
 === How does closed mode affect on-device debugging? ===
-[[User:lma|lma]] For example, will ptrace(2) still work (eg gdb, strace & ltrace)?  Will we be able to produce code dumps?
+For example, will ptrace(2) still work (eg gdb, strace & ltrace)?  Will we be able to produce code dumps?
 --[[User:elena_r|elena_r]] 09:00, 28 October 2009 (UTC):For security reasons the idea is that a developer should be able to debug its own code (application), but should not be able to assign a debugger to another process. Of course, the memory dumps, for example of the kernel memory, should be restricted, too. This is valid for the "normal mode". For the "open mode" one should be able to do everything.