View Full Version : Windows Playready DRM?
Just seen this slide http://www.umpcportal.com/wp-content/uploads/2009/10/Capture_00075.jpg
The slide came via UMPC, but doesn't expand on it.
Is this restricting or just allowing drm files?
Rich
allnameswereout
2009-10-10, 20:28
This just allows DRM files to be played, and might mean Ovi Music support, or stuff in Silverlight (provided there is Silverlight support). IOW compatibility reasons.
It does not imply you suddenly don't own your device anymore. It merely means Windows Media DRM works out of the box.
Although I do wonder how they're gonna avoid tampering. Because DRM can always be circumvented.
Laughing Man
2009-10-10, 20:28
Probably means it has drm mechanisms in place that meet standards for playing that drm file. Not that it would block you from non drm files.
Although I do wonder how they're gonna avoid tampering. Because DRM can always be circumvented.
Absolutely. All you need to do is play it once the 'legit' DRM way, then resample the audio stream to another format. Poof...DRM gone bye bye!
I buy all my digital music from Amazon anyway.
This just allows DRM files to be played...
It was to be expected. For a while now, Nokia has been saying that Maemo doesn't support DRM "yet".
But it's a pity. There was a chance for Nokia to endorse alternative music models here. If iTunes can successfully sell DRM-free songs, why not Nokia?
allnameswereout
2009-10-10, 20:43
It was to be expected. For a while now, Nokia has been saying that Maemo doesn't support DRM "yet".
But it's a pity. There was a chance for Nokia to endorse alternative music models here. If iTunes can successfully sell DRM-free songs, why not Nokia?Yes, agreed, 'yet'.
Although nowhere does it say its only for Ovi Music.
I want DRM and Silverlight (or Mono) on my Maemo device because I want to see broadcasts of e.g. football and olympics while traveling. For the rest, I won't use it.
It does not imply you suddenly don't own your device anymore. It merely means Windows Media DRM works out of the box.
Read this and thought great, but then just read the a comment on the summit blog about an open or closed mode for networks, whatever that is, in Maemo 6?!
allnameswereout
2009-10-10, 21:34
Read this and thought great, but then just read the a comment on the summit blog about an open or closed mode for networks, whatever that is, in Maemo 6?!Hmmm. Haven't read that. Do you have a reference?
Hmmm. Haven't read that. Do you have a reference?
It was mentioned here,
http://thenokiablog.com/2009/10/10/maemo-summit-liveblog-day-2/
----
15:43 [Comment From brainimpact]
as maemo 6 as a open and closed mode get ready for a battle with networks who will try get the switch removed in the devices they stock
----
Read this and thought great, but then just read the a comment on the summit blog about an open or closed mode for networks, whatever that is, in Maemo 6?!
The phone companies (if you were asking what "networks" meant in that sentence).
The phone companies (if you were asking what "networks" meant in that sentence).
Yeah I know that, I was wondering what the 'open or closed mode' was, sounds ominous. Hoping someone has the wrong end of the stick.
Yeah I know that, I was wondering what the 'open or closed mode' was, sounds ominous. Hoping someone has the wrong end of the stick.
If I understood it correctly (I am not at the summit): You can choose if you want to put the device into a mode where it is "DRM ready" which may disallow you to do some things, like becoming root for example.
Or you can choose to put the device into open mode, which means that you cannot use applications relying on Digital Restriction Management at that time (or rather that those apps probably will not run then).
Which I think is an okayish trade-off.
allnameswereout
2009-10-10, 22:01
It was mentioned here,
http://thenokiablog.com/2009/10/10/maemo-summit-liveblog-day-2/
----
15:43 [Comment From brainimpact]
as maemo 6 as a open and closed mode get ready for a battle with networks who will try get the switch removed in the devices they stock
----Thank you. It is a reference to Harmattan Platform Security talk by Elena Rashetova, quoted at 15:18 - 15:21. There are a few slides photographed but they're unfortunately not viewable (too bad quality) but since all talks are recorded to be broadcasted later we can look into it later. :)
If I understood it correctly (I am not at the summit): You can choose if you want to put the device into a mode where it is "DRM ready" which may disallow you to do some things, like becoming root for example.Its something like allowing the user to enable/disable DRM. In a case it is enabled, the hardware will try to make all digital holes closed (since analog hole always exists).
Or its more system wise far more advanced than disabling root access, akin to signed binaries (like a Symbian or iPhone jail) and capability-based security.
Makes sense because sometimes, a N900 is given to employees and you don't want them to install the latest spyware on it, or remove the killswitch in case its stolen, or ...
IMO signed binaries are a good thing. Why would I trust running software from some shady person? Same for capabilities. Why would a browser require access to all files in ~/.* including your mail dirs?
If I understood it correctly (I am not at the summit): You can choose if you want to put the device into a mode where it is "DRM ready" which may disallow you to do some things, like becoming root for example.
Or you can choose to put the device into open mode, which means that you cannot use applications relying on Digital Restriction Management at that time (or rather that those apps probably will not run then).
Which I think is an okayish trade-off.
In exchange for enjoying what the media companies have deemed you worthy of being allowed to sample (via ball and chain) you must give up freedom and control over your device.
DRM is a tradeoff that always leaves the end-user less free. I hardly see how that is even "okayish" much less remotely acceptable.
Janne Heikkinen, head of product planning, mentioned DRM support for Maemo 6 in his keynote on Friday. Elena Reshetova, Security specialist had a lightning talk today about the two modes the security framework will enable in Maemo 6.
The examples of DRM based services provided were Ovi Store (http://store.ovi.com) and Comes With Music (http://www.comeswithmusic.com/).
The Maemo 6 security framework addresses other technical aspects apart from DRM. In short, Maemo users and developers willing to have full open access to their devices will continue to be able to do so just like now. As a consequence, DRM related services and other security control points will be removed from the system. If those users or developers want to return to the original DRM enabled configuration they will be able to do so. Their choice.
In exchange for enjoying what the media companies have deemed you worthy of being allowed to sample (via ball and chain) you must give up freedom and control over your device.
DRM is a tradeoff that always leaves the end-user less free. I hardly see how that is even "okayish" much less remotely acceptable.
Then turn it off if you do not want it. That is what I meant with okayish trade-off - nobody puts a gun to your head and tells you "Sorry, not your device".
Although I really don't see why Nokia thinks it must push restricted music - I thought the music industry had learned at least *that* lesson.
allnameswereout
2009-10-10, 22:42
In exchange for enjoying what the media companies have deemed you worthy of being allowed to sample (via ball and chain) you must give up freedom and control over your device.
DRM is a tradeoff that always leaves the end-user less free. I hardly see how that is even "okayish" much less remotely acceptable.Its either being able to watch DRM video having the freedom to watch online over Internet e.g. Olympics or football championships. IOC and UEFA demand the DRM.
Or, having to rebroadcast it myself while I don't have upload capacity on my home connection).
Or, DVB-T/DVB-H, but don't think works on N900.
Or, not being able to watch it mobile.
Where is your choice now?
I'll take the freedom of choice to enable or disable DRM then. And, its great that it can be reenabled and redisabled in future point.
Plus, you'd not want some employees being able to fiddle with the device, given how incredibly dumb they are with technology. Lets be able to protect your business interests because 3G 24/7 connectivity opens a can of worms.
@qgil are there plans to port over Fluendo codecs to Maemo, or Moonlight to Maemo?
Then turn it off if you do not want it. That is what I meant with okayish trade-off - nobody puts a gun to your head and tells you "Sorry, not your device".
Are you sure about that? After all, if you can replace the kernel then you can do whatever you want with the data.
Although I really don't see why Nokia thinks it must push restricted music - I thought the music industry had learned at least *that* lesson.
They have, but fools in the media think that DRM actually works.
allnameswereout
2009-10-10, 23:07
Are you sure about that? After all, if you can replace the kernel then you can do whatever you want with the data.Indeed, so probably they'll use signed .deb and signed binaries and if you enable DRM you have to download and install those first.
Which indeed will replace your kernel again, and won't run the backdoors you installed because they're not signed binaries.
Together with capability-based security (such as limiting the browser local access even though able to run JS, Java, Flash, etc) you'll have a good jail.
Ofcourse, part of the DRM is hardware-based. Even though there may be a local exploit in some software, root access has to be gained while execution is difficult because of signed binaries and capability-based security plus, question is what root access exactly implies in such context.
I mean... you're aware the Symbian jails are pretty hard to break, right?
I put a link to Comes With Music for those not familiar with the concept. You might like the idea or not, but if you like it I personally can't think of a way to implement it without some kind of DRM.
http://en.wikipedia.org/wiki/Comes_With_Music#Comes_With_Music
Laughing Man
2009-10-11, 01:51
Any jail can be broken out of given enough people who are pissed off and determined enough to do it. Even if it requires a hardware hack which would limit the amount of people who could do it. It would eventually be possible.
Not to mention the article you linked qgil said that it can be downloaded to PC or Mobile. Even if people didn't bother with it on the Mobile they could just do it all on the PC.
The DRM I'm more concerned about is regarding applications. Seems that you will be forced to choose between a DRM closed system and an open system down the line (if I'm reading your post #15 correctly)
In physics pressure is less likely to break a closed system if there is an evident gate to the outside. This is why in Maemo 6 the possibility of switching modes will be officially supported and documented.
If you have purchased applications using DRM to handle their licensing rights then obviously you won't be able to use those apps if you get rid of DRM support in your system. If you don't like this combination you can contact the developers relying on DRM solutions for their business models. Or choose the software and services you use consistently according to your DRM preferences.
With this flexibility in the Harmattan system, I personally think you can't blame Harmattan itself and its security framework providing such choices. Is there any consumer electronics product offering officially such a feature? I think this is a good step trying to conciliate existing business models with software freedom.
jodyfanning
2009-10-11, 07:53
I think everyone is confusing Ovi Music with "Comes with Music".
Ovi Music is just a music store like any other. I understand it will become DRM free sometime.
Comes with Music is more like a music subscription service, such as Zune Pass or Rhapsody. And those will probably always remain DRMed.
allnameswereout
2009-10-11, 07:56
Any jail can be broken out of given enough people who are pissed off and determined enough to do it. Even if it requires a hardware hack which would limit the amount of people who could do it. It would eventually be possible.In theory, yes. In practice, if you rely on services you're gonna need authentication. And some jails are damn hard to break. Such as Playstation 3 and Symbian.
vivainio
2009-10-11, 08:09
This is why in Maemo 6 the possibility of switching modes will be officially supported and documented.
Will the "open" mode be fully usable, e.g. for making phone calls?
Will the "open" mode be fully usable, e.g. for making phone calls?
Elena will give more details in her session today and if you are in tyher Maemo Summit you can ask her, but in short: yes.
Basically, the same levels of freedom of Maemo 5 will be available for those willingin to enjoy them in future releases..
benny1967
2009-10-11, 08:33
Oh, the joys of going mainstream... :(
The Digitally Restricted Mode in Maemo 6 may be OK if changing between the two modes is as easy as checking/unchecking a box in the settings menu... (and maybe restart).
If it requires more than just that (like connecting the device to a PC via USB and issue a command similar to R&D mode), the game's over for good.
It may also be OK if what you cannot do outside the DRM-jail is restricted to the absolute minimum: run applications and play media that are defective by design. It might well happen that for some reason it's decided that, say, access to the telephony-components is only possible in restricted mode. That would be unacceptable.
Also, it must not be possible for resellers to manipulate the device in a way that it becomes DRM only. Yes, one could argue that even then it's still your choice where you buy it from, but: Having a majority of devices out that can't even switch to DRM-free mode would encourage Nokia to make Maemo 7 or Maemo 8 DRM-only. (This is what I fear most: that Harmattan is the last iteration that provides a DRM-free mode at all)
One thing I have to say, though, even though I'm very embarrassed:
I do hate and fight the idea of DRM... but Nokia's Comes With Music on a Maemo device would be something I'd use. I'm a hypocrite.
Another side note:
It will be interesting to see how they implement DRM technically on top of a free system... And if their solution - once Maemo gains momemtum - will make it over to the desktop. Anyone here has an idea how it could be done?
Peter@Maemo Marketing
2009-10-11, 08:47
It was to be expected. For a while now, Nokia has been saying that Maemo doesn't support DRM "yet".
But it's a pity. There was a chance for Nokia to endorse alternative music models here. If iTunes can successfully sell DRM-free songs, why not Nokia?
We at Nokia have not said that we will not continue to support alternative music business models than DRM-protected music content distribution. What we have said is that we will add a business model for music distribution which we do not have on Maemo yet i.e. DRM protected content. If we want take open source based consumer electronics to mainstream then we have to enable all common content distribution business models: DRM and non-DRM protected content.
Basically, the same levels of freedom of Maemo 5 will be available for those willingin to enjoy them in future releases..
Can network operators stop this? Can sim locking remove the 'open' mode?
Good that officially both modes are supported with documentation, providing those pesky networks can't interfere with the open mode capability.
Is all of OVI store in closed mode? Does that include Nokia Maps? Or does it fall under OVI and therefore all DRM'd? Nice if free stuff on OVI could be used.
Rich
The Digitally Restricted Mode in Maemo 6 may be OK if changing between the two modes is as easy as checking/unchecking a box in the settings menu... (and maybe restart).
The following is entirely guess work: I imagine to switch between the modes will require a reflash. Maybe there will be a dual-boot option. I would expect all your content (including address book) in one mode to not be accessible in the other. If this doesn't require a reflash or dual-boot then I would be very surprised, as anything less that would likely be hackable.
Laughing Man
2009-10-11, 14:17
In theory, yes. In practice, if you rely on services you're gonna need authentication. And some jails are damn hard to break. Such as Playstation 3 and Symbian.
It is like qgil said, with the case of the PS3, the linux mode defused the amount of people interested in hacking the PS3 because of homebrew. Yet the Wii and iPhone have no path and both Apple and Nintendo insist on clamping down which is why it's so prolific.
Meh, maybe you'll be able to dual boot though that (drm free and drm as two different OS) seems like a silly option if you want to be able to use DRM apps alongside apps that won't work in a DRM system. Oh well if this is the case maybe someone will create the darkside of maemo offering drm cracked apps haha.
allnameswereout
2009-10-11, 14:18
The following is entirely guess work: I imagine to switch between the modes will require a reflash. Maybe there will be a dual-boot option. I would expect all your content (including address book) in one mode to not be accessible in the other. If this doesn't require a reflash or dual-boot then I would be very surprised, as anything less that would likely be hackable.Why would such switch force one to remove non-executable data [such as] address book, or content in general? I don't see the point of that. If you simply only allow execution of signed binaries its fixed. If we assume reflash necessary, while the binaries are on / then why would say /home which is on a separate partition be overwritten? Makes no sense. Don't touch it unless user says so for it is merely readable data; not executable data.
Given you can run this all in a VM (SDK) and there can emulate DRM authentication (you own the hardware and software the SDK runs under) it'll be easier to crack than say Symbian (embedded w/o SDK+VM; is no S60 emulator) or Playstation 3 (expensive BluRay, again no emulator or VM). All what is required is a VM-based rootkit.
allnameswereout
2009-10-11, 14:20
Meh, maybe you'll be able to dual boot thoughIndeed, there is MicroSD. On Wii thats quite useful too (SD) for homebrew. On PS3 however, you have to resort to BluRay [...]
benny1967
2009-10-11, 14:34
The following is entirely guess work: I imagine to switch between the modes will require a reflash. Maybe there will be a dual-boot option. I would expect all your content (including address book) in one mode to not be accessible in the other.
Can anyone who attended the platform security (...) stream today comment on this?
This would be the worst nightmare come true... If the the change between digitally restricted and free mode requires a complete reflash and/or results in loss of data, DRM-free Harmattan will probably remain theory.
I'd hoped that you could boot into a restricted system (meaning OS restored to unaltered defaults, some applications won't be allowed to run and maybe even some files will not be accessible) or into a free system (hacked kernel OK, but certain files from restricted version unaccessible), with whatever isn't relevant to DRM (like my contacts or images I took) remains unaltered and shared between the 2 variants.
I'm spoiled, I know, but I would expect a Maemo device to let me switch back and forth on the go.
(OTOH: What is it that users as well as developers can't do in restricted mode? What would you want to do that would require DRM-free mode? I need more information before I can go into full DRM-rant-mode here...)
konttori
2009-10-11, 14:43
You can dualboot. Bootloader protects the kernel. If you boot to non-signer kernel, drm is off (as well as any features that need it).
allnameswereout
2009-10-11, 14:56
You can dualboot. Bootloader protects the kernel. If you boot to non-signer kernel, drm is off (as well as any features that need it).Thanks for the clarification.
Which Nokia applications are going to utilize DRM?
Will Ovi Maps require DRM?
Will there be additional advantages in DRM_is_on mode, much like on Symbian (signed binaries, capability-based security)?
shadowjk
2009-10-11, 16:42
Although I really don't see why Nokia thinks it must push restricted music - I thought the music industry had learned at least *that* lesson.
Pushing music/content that randomly stops working when the providers shuts off their drm servers (hello Yahoo, MS), or the provider in a Big Brother moment decides you can't have the file (hello Amazon), or you hose your OS and reinstall, etc, is a very user-hostile thing to do... Inexperienced users might get burned by DRM once and lose their files, after that they'll surely stick to piracy...
Not that I condone it, but when the choice is between paying for broken stuff that doesn't work, and not paying for stuff that works, something is wrong...
RevdKathy
2009-10-11, 16:46
Pushing music/content that randomly stops working when the providers shuts off their drm servers (hello Yahoo, MS), or the provider in a Big Brother moment decides you can't have the file (hello Amazon), or you hose your OS and reinstall, etc, is a very user-hostile thing to do... Inexperienced users might get burned by DRM once and lose their files, after that they'll surely stick to piracy...
Not that I condone it, but when the choice is between paying for broken stuff that doesn't work, and not paying for stuff that works, something is wrong...
You heard about my problem with tesco, didn't you!?!
No, I haven't resorted to piracy, but that's exactly what happened: tesco randomly decided to redesign their website and wipe my history. No more "If you have a problem, you can just redownload". I will never buy drm again.
Even Google did it (http://blogoscoped.com/archive/2007-08-11-n74.html):
Hello,
As a valued Google user, we're contacting you with some important
information about the videos you've purchased or rented from Google Video.
In an effort to improve all Google services, we will no longer offer the
ability to buy or rent videos for download from Google Video, ending the
DTO/DTR (download-to-own/rent) program. This change will be effective
August 15, 2007.
To fully account for the video purchases you made before July 18, 2007, we
are providing you with a Google Checkout bonus for $20. Your bonus
expires in 60 days, and you can use it at the stores listed here:
google.com/checkout/signupwelc ... The minimum purchase
amount must be equal to or greater than your bonus amount, before shipping
and tax.
After August 15, 2007, you will no longer be able to view your purchased
or rented videos.
If you have further questions or requests, please do not hesitate to
contact us. Thank you for your continued support.
Sincerely,
The Google Video Team
Google Inc.
1600 Amphitheatre Parkway
Mountain View, CA 94043
"You will no longer be able to view your purchased videos!"
That's why DRM is unethical.
Regards,
Roger
Laughing Man
2009-10-11, 17:33
HAHAHAHA, I love how Google tries to make it up to you by giving you Google Checkout money back. But then gives it an expiration date of 60 days.
allnameswereout
2009-10-11, 17:35
"You will no longer be able to view your purchased videos!"
That's why DRM is unethical.Depends on the license.
Comes With Music is rather a service. It allows you to listen to unlimited music for a specific period of time.
Comes With Music ... allows you to listen to unlimited music for a specific period of time.
Does it? I thought if you broke your device, you lost all your music. I'm happy to be corrected if that's not the case.
HAHAHAHA, I love how Google tries to make it up to you by giving you Google Checkout money back. But then gives it an expiration date of 60 days.
This caused quite an uproar at the time. Google eventually relented and offered a proper refund. But everyone still lost the videos they'd purchased in Google's "download-to-own" program.
Laughing Man
2009-10-11, 17:47
Does it? I thought if you broke your device, you lost all your music. I'm happy to be corrected if that's not the case.
"On December 4, 2007, Nokia unveiled their plans for the "Nokia Comes With Music" initiative, a program that would partner with Universal Music Group International,Sony BMG, Warner Music Group, and EMI as well as hundreds of Independent labels and music aggregators to bundle 12, 18, or 24 months worth of unlimited free music downloads with the purchase of a Nokia Comes With Music edition phone. Following the termination of the year of free downloads, tracks can be kept without having to renew the subscription. Downloads will be both PC and mobile-based." 1 (http://en.wikipedia.org/wiki/Nokia#Comes_With_Music)
So it looks like it can be kept on the PC or device itself. Though frankly I rather not pay the fee at all and not get the Comes With Music.
allnameswereout
2009-10-11, 17:51
Well the difference is that you never 'owned' a license for the downloaded content. Instead you have a contract to download for free unlimited music for X months. I don't know how exactly the synchronization stuff works, but my point is that its different from the examples given where licenses to listen to DRMed music were sold which then was copied to harddrive. I even find broadcasted DRM content like football or Olympics different from the examples too.
I wonder if it will turn up so, that there will at least a small anti-DRM movement. People will crete apps that will not work if DRM is activated, just opposite to those apps which will not work if DRM is not on..
vivainio
2009-10-11, 18:50
Given you can run this all in a VM (SDK) and there can emulate DRM authentication (you own the hardware and software the SDK runs under) it'll be easier to crack than say Symbian (embedded w/o SDK+VM; is no S60 emulator) or Playstation 3 (expensive BluRay, again no emulator or VM).
I don't think there is a full VM/emulator for maemo either. Or are you saying you got useful work apart from compilation done on ARM qemu? ;-)
IIUC the sdk vm images they are shipping are just ubuntu images with scratchbox.
You could theoretically create a hacked kernel image that "looked like" the "secure" one for the applications, bypassing the Fritz chip completely, but I don't see the point. It's probably easier for the consumer just to skip the services that require DRM and stay in the "Open" mode.
My concern with this sort of move is that some developers who would be prepared to deal with a DRM-free platform if that's all that was on offer, will instead choose to make apps DRM only if it seems like an easy choice. If that happens we'll get the split that Android has between the 'developer' and normal phones and there'll be an overall chilling effect on the Maemo ecosystem. Plus, people will inevitably try to break the DRM system which will put Nokia in direct opposition to a large chunk of their (potential) developers.
All this to support a model the music industry's already moving away from - it doesn't seem worth it.
in the end its all about a bunch of large incumbents seeing their reason to exist go up in smoke...
funny that corps can pull the rug under their workers with the excuse of efficiency, but pull the rug under the corps and there is "holy" wrath to be had...
You could theoretically create a hacked kernel image that "looked like" the "secure" one for the applications, bypassing the Fritz chip completely, but I don't see the point.
Well, if they do the DRM right, it works the opposite way. The binary is encrypted and will not run without it being decrypted by the chip and maybe some more. The whole chain to start the process is also verified with checksums etc., so one should not be able (easily) to dump the unencrypted version from the memory. The same way the whole audio chain is locked when an DRM'd music is played.
It's probably easier for the consumer just to skip the services that require DRM and stay in the "Open" mode.
Depends, if the price is right and I'll be able to get my data out of the software when I want so I could move it somewhere else (no lock-in), I would consider buying DRM'd stuff. Furthermore, I understand what the money lost by widespread "free copy" means for a small business doing quality work. Not always, but often, the open source stuff just is missing the last mile to be that tangible "quality". That is what the businesses should and have to do if they want to sell their stuff.
But.. DRM should not be forced, so that all commercial software would to be locked - most of it will be anyways cracked. I think better way to fight common piracy is the "release often" - people like to have the latest version with all the nice whistles and bells and they won't have it if they pirate stuff. Other thing what companies have been doing is to have value adding services online which are not available for pirates.
My concern with this sort of move is that some developers who would be prepared to deal with a DRM platform if that's all that was on offer, will instead choose to make apps DRM only if it seems like an easy choice. If that happens we'll get the split that Android has between the 'developer' and normal phones and there'll be an overall chilling effect on the Maemo ecosystem.
That is one of my fears too.. and what I'm more worried is obsolesce by software. The device would be obsolete not because of the hardware would not do the job but because of the software can not be updated to stay current.
Suppose that your device will be 2 years old and still working perfectly. The support has ended for your product as now there are new devices with ARM&LEG2000 chip which has some nice new and enhanced talents. The OSS has progressed in these years and you would like to upgrade it to make it faster and nicer, as you can do with any old PC with Ubuntu. You would also install some new commercial software, but your old libraries are not supported anymore. But if your update your kernel and base libraries, all DRM'd stuff you bough will stop working. Consequently, as your device is old and not supported the outside source software stack will never be supported. Now, if you think 2 years too short time for this to happen, then think 4, 6.. To give some though, this is already happening. My gf is using my old 770 while commuting and is perfectly happy OS2008HE setup I have rolled in, but I can see that the software is now bitrotting.. (Fortunately there is no DRM'd software, I have high hopes for Mer :) )
allnameswereout
2009-10-11, 20:20
I don't think there is a full VM/emulator for maemo either. Or are you saying you got useful work apart from compilation done on ARM qemu? ;-)
IIUC the sdk vm images they are shipping are just ubuntu images with scratchbox.
You could theoretically create a hacked kernel image that "looked like" the "secure" one for the applications, bypassing the Fritz chip completely, but I don't see the point. It's probably easier for the consumer just to skip the services that require DRM and stay in the "Open" mode.No, not necessarily a hacked kernel, actually if it checks checksum right after bootloader that is gonna be a bit hard. Provided it doesn't use CRC32 for that.
We're not talking about the average consumer. Or, at least, I am not. I'm talking about a Maemo version of Jon Lech Johansen.
Since one can (theoretically) run the whole Maemo 5 OS on SBox, the hacker can indeed use a rootkit for QEMU. Once that is works its childs play to jailbreak the device. For example, spoofing or ignoring some system calls. MITM is also a potential vulnerability. Or one local hole in one of the bundled software.
vivainio
2009-10-11, 20:49
No, not necessarily a hacked kernel, actually if it checks checksum right after bootloader that is gonna be a bit hard. Provided it doesn't use CRC32 for that.
The device would be running in "open" mode with the hacked kernel, so the checksum failure is not a problem. The hacked kernel can do anything it wants, including "impersonation" of the locked down kernel to applications. How applications can determine whether or not they are running in the open or locked environment is anyone's guess now that the system is not deployed yet. Basically, I'm thinking of the use case where you have an app that wants to run in closed environment, but can be fooled to think it has such an environment when it in fact doesn't (so it would store drm keys to normal filesystem, etc...).
We're not talking about the average consumer. Or, at least, I am not. I'm talking about a Maemo version of Jon Lech Johansen.
Yep, that's the only "target audience" you need to think of when designing a system like this ;-). We can imagine there will be people with custom hardware trying to hack this thing. Again, hacking doesn't seem to be "required" to use this phone normally (unlike w/ android and iPhoneOS), so I don't care either way.
Since one can (theoretically) run the whole Maemo 5 OS on SBox, the hacker can indeed use a rootkit for QEMU.
SBox doesn't run the target kernel, which is the most important part in scheme like this, so attacks from this direction are probably ineffective.
allnameswereout
2009-10-11, 21:19
Hmmm, you're right about SBox, but you already do run a Linux kernel. You could run the very same Maemo 5 Linux kernel in an ARM emulator (QEMU...). However because the hardware isn't emulated it probably won't work in that DRM-mode even though you enabled it.
What is even easier is if you can run QEMU on the N900 itself. For that it needs host and guest support. You then backdoor the QEMU VM, and let it run everything signed, while in reality you're in control via the backdoor (rootkit). From there the hard core fun part begins.
At least you can execute arbitrary code, and start debugging to learn how the DRM works. Then you need to develop a library which emulates the DRM and you're done. Or just hexedit the DRM library a bit. SoftICE would also help. The part to pay attention to is where it determines authentication is correct or not.
On OSX it'd be wiser if they'd keep their jailbreak intact and gradually figure wtf changed in the new firmware and slowly but surely import the new binaries in an already broken jail.
I don't care much either, btw. I find Comes With Music a rather fair service. Plus, I do wish it'll be easy to make micro payments. Like for example, a week subscription for Ovi, signed up & paid for in 3 or 4 'touches'. Lost in Spain? Bah. Buy a license for 5 EUR.
Besides, its the freedom of the developer to pick DRM. I just don't believe it generally works well unless its some kind of bulk service like Comes With Music. As soon as it really pisses off a talented techie the system will fail. Cause you gave him or her the itch to scratch.
Or, at least, I am not. I'm talking about a Maemo version of Jon Lech Johansen.
heh, the guy didnt really write the decryption bit of decss, what he did was make a windows front end, and distribute it on a web site registered in his name.
he was used as a example to try and scare others, only their choice of law to charge him by was poor. Said legal hole have later been closed, iirc...
whole thing was a legal circus on par with the pirate bay trial...
Well, if they do the DRM right, it works the opposite way. The binary is encrypted and will not run without it being decrypted by the chip and maybe some more. The whole chain to start the process is also verified with checksums etc., so one should not be able (easily) to dump the unencrypted version from the memory. The same way the whole audio chain is locked when an DRM'd music is played.
sounds like the trusted platform module (http://en.wikipedia.org/wiki/Trusted_Platform_Module) (note that trust in this case is coming from the media companies and others that want to trust YOUR computer can not do something THEY dont like) that supposedly is the basis for the microsoft's next-generation secure computing base (NGSCB (http://en.wikipedia.org/wiki/Next-Generation_Secure_Computing_Base), also known as palladium).
allnameswereout
2009-10-11, 21:58
sounds like the trusted platform module (http://en.wikipedia.org/wiki/Trusted_Platform_Module) (note that trust in this case is coming from the media companies and others that want to trust YOUR computer can not do something THEY dont like) that supposedly is the basis for the microsoft's next-generation secure computing base (NGSCB (http://en.wikipedia.org/wiki/Next-Generation_Secure_Computing_Base), also known as palladium).Thanks for refreshing memory regarding Jon. There can be various persons involved. If you do reverse engineering is even recommended. The guy who writes the frontend is important for end-users, but the guy who cracks the DRM is also important, obviously, as well as the guy who documents the specification. Maybe can be thrown again at 'implementing proprietary standard for interoperability' like with DVD.
The 'trust' is assigned to whoever owns the master keys. That could be anyone. IOW you can use hardware-based authentications like Fritz chip to your advantage. End-users can, power-users can, corporations can, government can, and those who sell you trojan horse with tech product can as well.
We have never seen a corporation sued for stopping DRM service of paid content (Microsoft, Google, ...), use remote killswitch (Apple, Amazon), intentionally crippling hardware (Nintendo, Sony), or heck using DRM itself on remote devices...
We have never seen a corporation sued for stopping DRM service of paid content (Microsoft, Google, ...), use remote killswitch (Apple, Amazon), intentionally crippling hardware (Nintendo, Sony), or heck using DRM itself on remote devices...
i could have sworn there was rumblings of class actions on both one of the DRM server shutdowns, and the amazon kindle mess, but at either time the corporation involved relented in some way so that the whole thing dried up...
Just found http://mer-l-in.blogspot.com/2009/10/maemo-security-lockdown-or-liberation.html - cool!
I'll try to get Elena's slides up asap. I don't even know whether she is working today so bare with us if it takes one day.
We'll keep checking the wiki page and answering there (mostly Elena since she is the specialist). I'll keep also following here in order to help clarifying things on the emotional side. :)
For instance:
DRM is not in the way if you want to enjoy free content or free apps. It's not that you would need to choose between "official stuff + DRM" or "community stuff + freedom". In practice the use cases might well be:
- User has a DRM enabled device as it came out of the box, with DRM and DRM-free content and applications.
- User has a DRM enabled device as it came out of the box, but the DRM feature is unused since he deals only with DRM-free content and apps.
- User really can't stand DRM and he has gone to DRM-free mode (officially documented and legal), keeping the same access to all the non-DRM content and applications, free or commercial.
About the lock-in "feature", the Maemo 6 security framework technically enables the possibility to configure locked systems, which is a potential requirement from e.g. operators. Another different question is whether there is a corporate customer interested in the commercializations of such devices. What we are saying is that no matter what user will have access to new Maemo flagship devices unlocked, at least through the official Nokia distribution channels.
My *personal* opinion with my software freedom hat on: if someone voluntarily signs a contract with an operator for a locked-in device and voluntarily purchases DRM apps or content, then I don't see what ownership and freedom rights can he really claim. If freedom is so important for someone then get an unlocked device, get DRM-free apps and content and be good with it.
About the simplest way to switch from one mode to the other, it's too soon to tell. I guess the desirable scenario would probably be rebooting from one mode to the other e.g. through an option in the power button menu. We'll see.
If Nokia supplies devices in such a locked down configuration then you're going to have real problems with any software licensed under the GPLv3 because of its 'anti-tivoisation' provisions. AIUI the Maemo platform (unlike e.g. Android) has quite a lot of FSF/GNU software in it, and they're obviously keen to push GPLv3.
...What we are saying is that no matter what user will have access to new Maemo flagship devices unlocked, at least through the official Nokia distribution channels...
Provided that remains true in the future, then we have no problems.
...if someone voluntarily signs a contract with an operator for a locked-in device and voluntarily purchases DRM apps or content, then I don't see what ownership and freedom rights can he really claim.
Fair comment, if the user genuinely understands what's going on (which is often not the case when carriers cripple a product).
I would really like to see Nokia require carriers to use a different model number (or at least a suffix) when they provide a device with different functionality compared to the device provided directly by Nokia. At the moment, some carriers do this anyway, and some don't.
Regards,
Roger
Nokia has a good knowledge of licenses including the GPLv3. In fact Nokia was one of the companies involved in the GPLv3 drafting process. Even if the v3 is in overall well seen by lawyers because of a more concrete and efficient legal terms, I believe the company also knows well the limitations this license offers to certain business models.
Until now Nokia has been fully respectful with all kinds of licensing models and of course this full respect will be kept in the future. The legal experts in the company are in touch with the FSF/FSFE and they take part in their activities.
Have also in mind that the own GPLv3 allows to developers adding exceptions e.g. Canola Project’s GPLv3 Permissions are Worth a Look (http://www.linux-foundation.org/weblogs/jzemlin/2009/06/01/canola-project%E2%80%99s-gplv3-permissions-are-worth-a-look/)
So let's see. What has been presented is a security framework technically able to offer a wide and flexible array of configurations. If someone is interested in the lock-in business model then they will need to pay attention to the licensing. Business as usual, on the other hand.
I wasn't in the Maemo Summit so I'm a bit in the dark about this and would appreciate if someone could possibly clarify some things.
First of all, I am talking about DRM here with regard to applications. I don't plan on using DRM'd music or video right now but I might end up using commercial applications or games that insist on some sort of DRM to (try to) prevent unwanted copying. I can live with that as long as I have the choice to use or not to use them. I also don't plan on buying a subsidised device from a mobile operator but an unlocked version.
What I'm wondering about is how much the "hackability" will be affected by this DRM scheme. Example: Some bluetooth profiles are missing out of the box in Maemo 6 like now and would require some hacking to make them work. Could I do this hacking with root access in the "open mode" and then boot back to the "drm-mode" to be able to run my DRM'd applications or games or voice-guided nav with Nokia Maps _and_ have the bluetooth profiles work or would I have to boot back to the "open mode" every time I wanted to use the profiles?
Another example could be something like plugging in accessories or peripherals that won't work out of the box and would require for example driver installation or configuration. In a case like this, am I able to do the driver installation/configuration in "open mode" and have these still work in the "drm-mode"? Or will it be an either-or situation?
jsa, these are good questions worth checking with the security guys through the wiki page. The real question is whether Harmattan users will need to move to an open mode to introduce or activate features not supported out of the box. They might be able to do this for instance through a maemo.org Extras add-on, perfectly valid out of the box.
DRM itself has nothing to do on whether applications will be able to get privileges to extend the functionality at those levels. I guess it's about seeing case by case since from a security point of view installing a driver, enabling a BT profile, speed the CPU clock and etc are each one a different case.
What I'm wondering about is how much the "hackability" will be affected by this DRM scheme. Example: Some bluetooth profiles are missing out of the box in Maemo 6 like now and would require some hacking to make them work. Could I do this hacking with root access in the "open mode" and then boot back to the "drm-mode" to be able to run my DRM'd applications or games or voice-guided nav with Nokia Maps _and_ have the bluetooth profiles work or would I have to boot back to the "open mode" every time I wanted to use the profiles?
Another example could be something like plugging in accessories or peripherals that won't work out of the box and would require for example driver installation or configuration. In a case like this, am I able to do the driver installation/configuration in "open mode" and have these still work in the "drm-mode"? Or will it be an either-or situation?
Yeah I'm aftraid of this too. I was hoping N900 and up will be more open and more hackable on the lower level (kernel, bootloader). This indeed looks like signed bootloader loading signed kernel with disabled (or signed?) kernel modules. So most probably no extra kernel drivers or otherwise you would be able to load anything into kernel and disable DRM in one way or another.
I am also worried that such locked down design will be used as excuse for not having some features available (no time for coding them because of priorities and extra DRM complications) or for not having source code available. It mayalso affect various design choices (choice of bootloader etc) so even people using only open mode will feel the limitations being present.
What we are saying is that no matter what user will have access to new Maemo flagship devices unlocked, at least through the official Nokia distribution channels.
That's good to know.
My *personal* opinion with my software freedom hat on: if someone voluntarily signs a contract with an operator for a locked-in device and voluntarily purchases DRM apps or content, then I don't see what ownership and freedom rights can he really claim. If freedom is so important for someone then get an unlocked device, get DRM-free apps and content and be good with it.
There is a slightly different scenario, signing a network contract, but not wanting to use DRM, is open mode available then?
I've heard the N900 has DRM functionailty, not sure if this is correct, but if it does and I buy from a network operator, then do I expect a locked down, restricted device? I fine with being sim-locked to the network, just not restricted with what the device can do on the back of DRM implementation. I currently don't have a phone contract and had planned to buy a N900 on contract, but potential DRM has put a doubt in my mind and maybe I should start saving to buy direct from Nokia!
Does anyone think it will be worth trying to educate the buyers of carrier-degraded Maemo phones? I'm thinking of something along these lines...
A desktop widget (with an enticing name such as "Free Desktop Widget" to encourage users to try it out). When it's running under open-Maemo, it displays the message "I am free!". When it's running under DRM-Maemo, it displays the message "I am shackled". If the user taps on the widget, it then pops up an explanation of how to enable open-Maemo mode.
Authors of open-source Maemo packages could introduce a dependency upon this widget if they liked the idea.
Regards,
Roger
richie, lock-in and DRM are different things. There are devices with both, just one or none. If you're interested, ask before buying a product. The N900 has no DRM and is available unlocked.
fanoush & co, your concerns and perhaps even suspicions are understandabe. Hopefully previous Maemo records, overall Nokia strategy and trends plus the fact that we have shared this Harmattan information even before the N900 is in the shops helps showing our willingness to share, discuss, and get into details as development goes further and things get more concrete.
Can I ask that the wiki page is used as a way of those of us who understand Elena's design (fantastic presentation and really good design given the requirements, IMHO) to ask questions in a structured and sensible way?
The more end-user/enthusiast questions can be dealt with through communication channels such as Talk and Planet; leaving the impact on Elena's (and others') time to be minimised?
So, good questions:
When Maemo 6 has booted into a "trusted" mode and has the DRM features available; will a maemo.org extras package be able to modify a file in the rootfs? Will postinst scripts run as root? Will root be available for modifying files installed for unverified binaries (such as editing a file my own app has installed?)
Can a signed image be booted into with an unsigned kernel, but with fewer capabilities available?
Bad questions:
Can't I just get root and modify /etc/init.d/... to turn off DRM and get at all my copy-protected music?
Why are you so evil to allow companies which are subsidizing my device to control what I do with it?
Certainly, once Elena's presentation (and the video) is online, I plan on writing up my own take on it, and helping lbt come up with a good list of questions. I don't want to scare Elena and the other security framework developers off from the community.
PS. The initial comments about "open" and "closed" device modes refer to people who want the full freedoms afforded them today. However, most users will still be able to dabble with a single paid-for app (using DRM to ensure copy protection) and get most of their apps from maemo.org Extras.
PPS. I spoke to Niels immediately after Elena's talk and there are two useful things we can do on Downloads (http://maemo.org/downloads/) and/or Packages (http://maemo.org/packages/): showing the capabilities requested by a package (by parsing its Aegis manifest) whilst a user is browsing the apps (before having to install it), and making the autobuilder check that an app doesn't request any privileges which aren't available to apps available through Extras.
PPPS. I'm very glad that the effort we're putting in to Extras QA and -testing isn't going to be wasted by users only being able to get community apps through Ovi Store if they want DRM. As I said, good design here.
Yeah I'm aftraid of this too. I was hoping N900 and up will be more open and more hackable on the lower level (kernel, bootloader). This indeed looks like signed bootloader loading signed kernel with disabled (or signed?) kernel modules. So most probably no extra kernel drivers or otherwise you would be able to load anything into kernel and disable DRM in one way or another.
However, there are two paths. If the kernel's signature is incorrect, and the device is not sim-locked, the unsigned kernel will be booted with DRM features disabled.
Those who are interested in hardware hackery for the end-user may have more problems, but most end-users don't need functionality provided by new kernel modules or kernels. And, if they do, and they require access to some DRM content, they'll need to use bootmenu.
However, there are two paths. If the kernel's signature is incorrect, and the device is not sim-locked, the unsigned kernel will be booted with DRM features disabled.
Yes, I didn't emphasized it, sure there will be two ways but with DRM disabled some stuff will not work so you e.g. cannot play game you bought with non-hid bluetooth keyboard (unless uinput is enabled in signed kernel) etc. That basically means modified kernels with harmless fixes will be a no go for people buying stuff from ovi store (i.e most regular people). We'll see how much this will hurt.
And then with all this restrictions and inconvenience in place, security exploit will be found in signed kernel, and all this is in vain anyway.
Those who are interested in hardware hackery for the end-user may have more problems, but most end-users don't need functionality provided by new kernel modules or kernels. And, if they do, and they require access to some DRM content, they'll need to use bootmenu.
As I said earlier, I haven't seen the presentation and even if I had I probably couldn't answer my own questions so I hope you could based on what you know at the moment. This is a simple hypotethic example
"If Maemo 6 still doesn't support bluetooth DUN out of the box will I be able to use it as my laptop modem and play a DRM'd game at the same time?"
I'm mostly concerned that if I want to use paid software I'm stuck with out of the box functionality. If someone in the know could rephrase these concerns to relevant technical questions to the security team and the responses back to layman answers I'd be very grateful.
As I said earlier, I haven't seen the presentation and even if I had I probably couldn't answer my own questions so I hope you could based on what you know at the moment. This is a simple hypotethic example
"If Maemo 6 still doesn't support bluetooth DUN out of the box will I be able to use it as my laptop modem and play a DRM'd game at the same time?"
The question here is how DUN is added on in Maemo 5. If it's just BlueZ configuration then, depending on the restrictions about modifying (rather than adding) the BlueZ files on the signed rootfs, it might be more possible than if a recompiled BlueZ is required.
And also what you mean by "at the same time" :-)
Certainly, there'll have to be more openness between Nokia and the community in getting uinput and other kernel features into the signed kernel.
I'm mostly concerned that if I want to use paid software I'm stuck with out of the box functionality. If someone in the know could rephrase these concerns to relevant technical questions to the security team and the responses back to layman answers I'd be very grateful.
It depends what you mean by "out-of-the-box functionality". If the functionality touches the low levels of the system, the chances increase that it might not work with a more locked down runtime. However, Quake 3 isn't available out-of-the-box, and that kind of additional application should still be trivial to ship through maemo.org Extras.
A question about changing configuration files for BlueZ and inserting unsigned kernel modules seems appropriate though.
solarion
2009-10-12, 16:03
qgil:
Magnatune has a similar all-you-can-download (as well as an all-you-can-stream) service without DRM. It sounds similar to Comes With Music; save that you'd then need to tie a device-specific ID (iirc, that's the wifi mac address on the n810 for the purposes of getting the flasher and updates) to a limtied-time subscription.
That's what came immediately to mind.
The question here is how DUN is added on in Maemo 5. If it's just BlueZ configuration then, depending on the restrictions about modifying (rather than adding) the BlueZ files on the signed rootfs, it might be more possible than if a recompiled BlueZ is required.
And also what you mean by "at the same time" :-)
Gotta multitask myself to oblivion. :) I mean having the DUN profile work in the trusted mode so that every time I want to tether, I don't have to reboot into the open mode.
It depends what you mean by "out-of-the-box functionality". If the functionality touches the low levels of the system, the chances increase that it might not work with a more locked down runtime. However, Quake 3 isn't available out-of-the-box, and that kind of additional application should still be trivial to ship through maemo.org Extras.
N900 examples
-receiving FM radio, possible but no support out of the box
-bluetooth profiles, missing DUN and PAN out of the box
-MMS, no hardware limitations afaik, only software
-USB host with the previous devices
And a USB host mode in a Maemo 6 device would bring even more potential awesomeness that would probably require some low-level meddling to get stuff work.
I mean this kind of added funtionality, not the Quake 3 kind. Nokia will probably fix these before Harmattan, but there will always be new ones.
Thanks for the clarifications, now I understand a bit better. So things like these end up to the signed kernel through Nokia?
Btw, This is just a thought, can someone actually make a program that is basically a switch.. It will give the user to switch the DRM on and DRM off?? It might be too early to know.. but is something like that possible?? jw.
Presentation slides are available, thanks Nokia,
http://www.slideshare.net/peterschneider/maemo-6-platform-security
lbt's blog (http://mer-l-in.blogspot.com/2009/10/maemo-security-lockdown-or-liberation.html) (thanks, qgil) raised a good point that has bothered me for a while now. With all of its new telephony features, the N900 can be seriously exploited by hackers, and we're going to have to work as a community to, as qgil said, encourage Extras apps and discourage the use of random, unknown repositories.
Having seen how easy it is to make a silly app for Facebook and get everyone to use it, it sends shivers down my spine to think of how hackers could post an .install file that points to a malicious repository full of nasty trojans and exploits disguised as fun little games.
We certainly need more security. Right now when I download an application from Extras-Devel it can do anything to my device; on an N800 that's not so bad - on an N900 that can incur significant cost and could conceivably (and almost trivially) be used to perpetrate fraud. I'd like to be able to say "no, scrabble game, you can't access my contacts data or make phonecalls - what on earth do you need to do that for?" An open security infrastructure would make me feel a whole lot more comfortable.
allnameswereout
2009-10-15, 16:38
Uh, yeah, that is the other part which goes hand in hand with signed binaries, the great capability-based security Symbian has. If you install an application in Symbian you can check the signature (and Symbian does itself too), and you can check the capabilities it requires. Actually, by default on E-Series, you will only be able to run executables signed by Symbian Foundation (this is a bit like an App Store jail) although one can enabled self signed binaries.
Linux (by default) lacks capability-based security although there are various ACL implementations (not same as capability-based security but tries to be) its being mentioned in the slide 6:
Principle of least privileges
Every application should be able to access only limited set of needed resourcesThis is a feature Symbian has, and Linux not (by default), and getting something akin enabled and working well takes a lot of effort. Especially all those policies. This is also a reason why N900/Maemo 5 is not ready for the masses. Yet... also, capability-based security asks the user for interaction to decide. This shifts control and responsibility to the user.
Trojan repositories are just one vector btw. There are more. Intentional programming errors, for example. Or unpatched vulnerabilities in Flash, Gecko which are patched by upstream but not backported by Nokia ...
Actually, by default on E-Series, you will only be able to run executables signed by Symbian Foundation (this is a bit like an App Store jail) although one can enabled self signed binaries.
As I understand it, even self-signed binaries had limited access to the system and full access was only ever provided to Symbian signed packages.
Were this to be implemented in Maemo, assurances would have to be made that self-signed (or even unsigned but manually installed) packages would have full rights to the system.
allnameswereout
2009-10-15, 16:50
For starters the packages can be signed with GPG. After that, the binaries. Nokia won't allow tampering with the DRM subsystem. Only authenticated resources can access the encrypted storage used for DRM. At least, that is what I understood from the slides.
I'm not sure about the Symbian subsystem being broken by 3rd parties. There are some guides floating around the net for that, but I haven't touched them. If they work these guides can be used by criminals, pirates, hackers (good type) alike...
It's important to separate the technology and the policy. Technology that helps me to protect my system and my data from apps I don't trust is good. If the policy says that it's used to protect apps and data from me, because the upstream suppliers don't trust me, then it's a problem.
For those intertesed I've just noticed that Elena at Nokia has kindly answered some of the questions about the security platform on the Maemo Security wiki page.
Rich
Ok, on the wiki page Elena replied about the security architecture. I still have few questions/clarifications but don't really want to clutter the page (even in discussion mode). Should I ask them here (does Elena reads this thread?) or should I edit the page? (then we need to find a way to do more constructed answer/replies because it won't be readable long)
Ok, on the wiki page Elena replied about the security architecture. I still have few questions/clarifications but don't really want to clutter the page (even in discussion mode). Should I ask them here (does Elena reads this thread?) or should I edit the page? (then we need to find a way to do more constructed answer/replies because it won't be readable long)
Add stuff here or on the discussion page and people'll moderate it into a sensible Q&A on the main page.
Ho, and another question (well, two in fact):
* will the Arm TrustZone be available and usable on n900?
* is there any security architecture available on Maemo 5?
(the two aren't completely independant though)
@qgil are there plans to port over Fluendo codecs to Maemo, or Moonlight to Maemo?
gst-inspect | grep flu brings up:
fluwma: fluwmsdec: Fluendo WMS Decoder
fluwma: fluwmadec: Fluendo WMA Decoder
If you use your own kernel, you are the one to set the security policy for the device, meaning that your SW in this case can make calls, send sms and so on (for example). Please note that the list of protected resources on the slide is given just as example (to show the possible granularity level), so it doesn't mean that we would have exactly these resources.
Ok, that means that, if we designed our own kernel with its security policy (I guess there will be some documentation to do that, but that looks very interesting and powerful), we could restrict it from doing something (like accessing cellular functions) easily. But that won't be enforced if we don't want to, it's up to the kernel maintainer.
Am I right?
Can open applications use the privilege mechanisms in the Open and Closed modes?
I guess the question is "Can the applications access protected resources in both modes?" I hope I got the question correctly. The answer is that the Device Security Policy (slide 7) defines the resources can be potentially granted to the SW coming from a particular SW source. When one uses the Nokia signed kernel, the device security policy is defined, and user can't change it. If one uses its own kernel (or community kernel for example), he (or community) is the one to define/change the device policy. This means that one can, for example, change the policy in the way that the SW coming from the maemo.org gets access to all protected resources (of course some content becomes unavailable when one switch to its own kernel, for example DRM). However, again, it is possible only while using your own kernel.
I fact, I don't meant that I wanted to access from open mode a ressource protected in closed mode.
But more, what, as I user (or, say, a company giving n900 (or a Maemo6 device) to its employee), can use from the security architecture.
Suppose I need to run a rebuilt kernel (because I need some functions not available in regular kernels), that means (slide 6) the device will “restrcict security functionality”. In particular, DRM keys will be disabled (I'm fine with that) “content from the previous mode can't be decrypted”.
I'm fine with the latter too, as long as I can still use the security architecture for personal needs, so still use encryption storage, use trustzone, be able to sign my own kernels, use security functions for VPN stuff etc.
Basically, will the Maemo6 security architecture still be usable outside of “nokia world“ and inside a “local business world”.
Not sure I'm really clear, feel free to ask precision :)
bossyboots
2009-10-23, 13:52
Read this thread and I have an emotional/geek question for Quim or Peter about using the x-terminal in Maemo 6.
Quim's blog post proudly shows off an x-term running on Maemo 5 and there is hack project with Nokia PUSH on the N900. So worried Maemo 6 has boring DRM restrictions.
I understand there is an open and closed mode, but I gather that Maemo Security will use access control that is likely to be implemented below Root level, so can't Maemo 6 continue with the x-term even in closed mode? I rarely need root level access, it is more about my preference to manage files using the x-term, using it for SSH and simple geekness of having an x-term on a handheld device!
NRC-TR-2008-010 (http://research.nokia.com/files/NRCTR2008010.pdf) is a year old but looks relevant and goes into a lot more detail than the talk & slides.
That is Elena' master thesis done while she was working at Nokia Research Center. Yes, we all have previous lives. :) Don't mix this document with Maemo Harmattan plans.
That is Elena' master thesis done while she was working at Nokia Research Center. Yes, we all have previous lives. :) Don't mix this document with Maemo Harmattan plans.
Though the document is indeed interesting and I invite everyone interested in security to read it. Elena again edited the wiki page with some more information about open / closed (normal) mode btw.
The wiki page doesn't seem to address policy - only technology, and the policy is the interesting thing. For example, as a matter of policy, will users with 'closed' mode devices be allowed to install software from maemo-extras?
Right :-) FWIW the other relevant-looking document that comes up when searching for linux and "mandatory access control" under nokia.com is this (http://doc.qt.nokia.com/qtextended4.4/sxe-framework.html) which talks about LIDS (http://www.lids.org/).
Anyway, although the actual mechanics of the implementation are interesting to geeks what we should be discussing openly is the policy to be implemented on top of these. There are already a few worrying things in the wiki discussion page (for example not being able to debug things on device will definitely hamper my bugzilla work). I understand the policies are not cast in stone yet, but that's exactly the right time to be discussing them.
Hi
Does anyone know if the summit video for the Maemo Security presentation is available now?
It is not listed here (http://wiki.maemo.org/Maemo_Summit_2009#Videos), but is the video hosted elsewhere?
Rich
Just like in any serious OSS conference, uploading the videos is taking longer than expected but we are working on it. :/
Just like in any serious OSS conference, uploading the videos is taking longer than expected but we are working on it. :/
No problem, look forwading to see them all when ready.
Cheers
Rich
Just like in any serious OSS conference, uploading the videos is taking longer than expected but we are working on it. :/
Yes, I hear uploading videos for silly conferences is a lot faster. ;) :D
I understand there is an open and closed mode, but I gather that Maemo Security will use access control that is likely to be implemented below Root level, so can't Maemo 6 continue with the x-term even in closed mode? I rarely need root level access, it is more about my preference to manage files using the x-term, using it for SSH and simple geekness of having an x-term on a handheld device!
In principle it could make use of Linux containers to support "side by side" DRM and no-DRM environments, with "root" available to the no-DRM environment, but the no-DRM environment is limited in what it can do to the DRM environment.
The kernel of course could not be modified if you have a DRM environment running.
In principle it could make use of Linux containers to support "side by side" DRM and no-DRM environments, with "root" available to the no-DRM environment, but the no-DRM environment is limited in what it can do to the DRM environment.
The kernel of course could not be modified if you have a DRM environment running.
What I mean is that arrangement could support things like third party unsigned BlueZ PAN and DUN support which was mentioned. That would run in the no-DRM environment. As long as it doesn't need kernel changes, only system daemons, that could be made to work.
Even some third party open source kernel modules may be possible, if there's a way to isolate them by running them in a kernel in a VM guest which has controlled access to host subsystems and devices.
Ideally the security module keeping DRM and no-DRM sides apart, with only safe interactions, should stick to the bare minimum of necessary restrictions. Preferably choosing the restrictions based on what DRM-using apps require at the time.
For example, the no-DRM side should be able to intercept all network packets in and out and, say, run it through it's iptables or fancy routing/tunnelling, just as it can now on Maemo 5 as root; there is no reason to block that sort of thing.
But the no-DRM side would be blocked from modifying files that the DRM side says it requires to be signed and managed by signed programs (all the way down to the kernel), and if the no-DRM side changed any of those files (including the kernel) or break any other invariants requested by a DRM-using app, then the DRM side would see the signature for those invariants is not available.
In summary, there's some scope for more fine-grained side-by-side behaviour than simply booting into DRM vs. no-DRM modes. It can resemble more closely a finer grained traditional or role-based security module, with signatures for fine-grained invariants which DRM-using apps request, which are granted only of no apps is breaking them at the time (or might have broken them earlier, depending on the particular invariant). And switching between modes can be more fine grained too.
The one thing which seems unavoidable is third party open kernels may not be able to provide any invariants to DRM-using apps - unless there is some trick of the hardware which can do that which is beyond even the kernel to defeat.
lbt's blog (http://mer-l-in.blogspot.com/2009/10/maemo-security-lockdown-or-liberation.html) (thanks, qgil) raised a good point that has bothered me for a while now. With all of its new telephony features, the N900 can be seriously exploited by hackers, and we're going to have to work as a community to, as qgil said, encourage Extras apps and discourage the use of random, unknown repositories.
Having seen how easy it is to make a silly app for Facebook and get everyone to use it, it sends shivers down my spine to think of how hackers could post an .install file that points to a malicious repository full of nasty trojans and exploits disguised as fun little games.
I agree and think this could become a big issue fast.
Android has non-standard changes to Linux, I'm guessing to help address this sort of thing.
Fortunately Linux provides containers and they are getting almost mature now ;-) which could be used for sandboxing even quite low-level apps with no significant loss in performance. For most apps, I'd expect they could run in a container quite well. They can still share libraries (Gtk, Qt etc.), including sharing the memory at run time with code outside the container or in other containers, and sharing config files, if the files are managed well.
On a related note... I just checked; Modest and all of the RTComm accounts (except Skype) still store all the passwords in plain text in GConf. It is trivial for any app to obtain these passwords at the moment.
Should I file bug(s) about this?
allnameswereout
2009-11-08, 01:37
On a related note... I just checked; Modest and all of the RTComm accounts (except Skype) still store all the passwords in plain text in GConf. It is trivial for any app to obtain these passwords at the moment.
Should I file bug(s) about this?Basically, no. It is architectural design, and the proposed solution is snake oil.
Plain text storage of password works as intended because somehow these passwords are stored and encrypted without user interaction because the user chose to save the password. What Skype does is obfuscate the password.
What should happen is this:
Barrier -> Authentication attempt (using input data; e.g. fysical key, smartcard, password, fingerprint, etc)-> Encrypt authentication -> Compare with saved key -> If match, authentication succeeded.
Then stop. However what happens is that after the above the input data is stored. If you provide one this input data they have access. Its like giving away your password.
Now, Skype obfuscates, because it is not known in which format Skype saves it. But if Skype can somehow decrypt the data without input data then so can someone else; they just need to figure out what.
Without obfuscation saving your password is akin to putting your house key before your door and then assume nobody will use it, or whine when someone does use it.
With obfuscation its akin to hiding your key in one of your plants in the front garden which supposedly nobody knows except a determined attacker can easily figure out about this.
This provides a false sense of security; snake oil.
Early UNIX versions did the very same thing, and together with lack of shadow file this made password cracking easy because /etc/passwd was readable by everyone.
If your application can read your program's configuration file and abuses this (arguably misplaced) trust you have worse problems. However, non-hostile applications do not do this.
If people dislike this they should use some form of authentication or a keyring like GNOME Keyring or KeePassX. This is pretty neat however a hostile application can ofcourse work around this.
IOW if this is an issue your solution should be dealing with core issue; hence, a rather architectural change. For example, applications isolated from each other. Then you get to levels such as privilege separation, VMs, ACLs, or microkernel + capability-based security. We do know Nokia is working on a framework to provide some of these mentioned features, but they won't be for Fremantle. Hence 'fixed in Harmattan' or WONTFIX seems rather a likely outcome.
Then stop. However what happens is that after the above the input data is stored. If you provide one this input data they have access. Its like giving away your password.
[...]
Early UNIX versions did the very same thing, and together with lack of shadow file this made password cracking easy because /etc/passwd was readable by everyone.
That's not quite true; the data in unix passwd file is not the input data, nor is it equivalent to a stored plain-text password. Getting a password from a passwd file entry required reversing a one way hash function - not impossible using a password guessing app, but it's a long way from 'giving away your password'.
If apps on the N900 are storing passwords or password equivalent tokens unencrypted in predictable locations, then that is a bug, and should be filed as one.
allnameswereout
2009-11-08, 18:22
That's not quite true; the data in unix passwd file is not the input data, nor is it equivalent to a stored plain-text password. Getting a password from a passwd file entry required reversing a one way hash function - not impossible using a password guessing app, but it's a long way from 'giving away your password'.You didn't understand what I wrote. Authentication with PAM or equivalent requires some kind of input data. If you _save_ your password then you simply _lost_ your chance to allow yourself to require input data.
If apps on the N900 are storing passwords or password equivalent tokens unencrypted in predictable locations, then that is a bug, and should be filed as one.There are 2 major differences with /etc/shadow:
1) /etc/shadow is only readably by root whereas any user application can read any one other user application's config files. Changing this requires serious work on the architecture of the OS.
2) the input data is encrypted and compared with the entry on /etc/shadow. If they match, the user is authenticated. Nothing is decrypted, ever. It'd make password cracking much easier. As I wrote, there is no input data if the passwords are stored, and if the passwords are not stored there is no issue.
The right way to solve the issue without too much changes (although still requires substantial work) is by using a keyring. In fact, many applications could make use of this. But the support for this has to be added in the applications, and you might as well wait a year for Harmattan which has DRM/ACL/capabilities support in the core OS.
PS: And like I wrote, if you have a hostile application which reads your passwords and abuses that then you have other worries. A hostile application could also log your keys, or be a worm. Really, the issue is much, much more different and complicated then. And this is exactly why capability-based security and signed binaries such as in Symbian is a Good Thing because it gives responsibility to those where it matters. The developer is known, their do's and dont's are known, when such isn't known they're denied.
You didn't understand what I wrote. Authentication with PAM or equivalent requires some kind of input data. If you _save_ your password then you simply _lost_ your chance to allow yourself to require input data.
This is true, however, you seemed (and indeed, seem) to be giving the impression that traditional unix passwd files saved passwords, and that this only changed with the move to shadow passwords. That is not the case.
You said that a major difference with shadow passwords is that:the input data is encrypted and compared with the entry on /etc/shadow.In fact, that's exactly how traditional unix passwords work too, the _only_ difference with shadow passwords is that the hashes are not stored in a world readable file.
allnameswereout
2009-11-08, 18:49
This is true, however, you seemed (and indeed, seem) to be giving the impression that traditional unix passwd files saved passwords, and that this only changed with the move to shadow passwords. That is not the case.Point #1 is about privilege separation.
Point #2 is related to what you assert. Because there is no input data there is nothing to be encrypted and compared with /etc/shadow.
The alternative to this is right there in existence and simple as kissing: do not save your password(s).
Again, I am not saying this doesn't warrant a bug report, but I am saying the problem is pretty much system-wide and architectural design instead of a problem easy to pinpoint in applications. The proposed solution, and very description of problem, do not solve the issue. They are snake oil pur sang.
And this is exactly why capability-based security and signed binaries such as in Symbian is a Good Thing
A "good thing" from the perspective of those who use them against you, because any such security scheme where authorization requires a 3rd party is implicitly holding you in the same level of contempt as any author of malicious software, and using your own property to enforce it.
It could be a good thing at best if such binary signing capabilities were made available to the user, with the ability for them to grant the highest levels of access should they desire (which, under Symbian, you definitely were not.)
The reasons this is in my opinion quite a bad thing for the open source/free sofware community are
1) people are forced to do choose between being free to do what they want with their device and being able to enjoy media, possibly some applications etc. In the worst possible case this means no proprietary apps or any movies, music etc. for you at all if you want an open system. In the best possible case this means you just won't be able to use some media that uses this but there will still be alternatives (albeit maybe more cumbersome to get on the device)
2) Even if things will be as described in the best possible case described in point 1 at first, if such a thing is accepted and becomes universal (that is MS finally gets around implementing a similar thing as they have been trying to etc.) there eventually will not be any or very little non-protected music, movies etc. that can be used on a device not using this "protection". This would mean becoming free would also prevent you from getting any entertainment that also wasn't a part of free culture.
Yes, the analog hole would still persist while we don't have DRMed eyes & ears but the quality degradation would be pretty severe... I'll say I will have a hard time justifying the purchase of a supposedly FLOSS-friendly device that also supports this divide.
epage's posts moved to http://talk.maemo.org/showthread.php?t=43627 , which is the current thread for the Security Framework discussion.
Everybody interested in this discussion please continue there since the scope is much wider than Windows Playready DRM.
vBulletin® v3.8.8, Copyright ©2000-2025, vBulletin Solutions, Inc.