Linux May Get A New Subsystem For RPMB: Replay Protected Memory Block

[phoronix]

Phoronix: Linux May Get A New Subsystem For RPMB: Replay Protected Memory Block

Patches surfaced this morning on the Linux Kernel Mailing List for implementing a new kernel subsystem...

http://www.phoronix.com/scan.php?page=news_item&px=Linux-Patches-RPMB

[FireBurn]

It sounds like the perfect place for a rootkit if this is ever gets exploited

[ssokolow]

It sounds like the perfect place for a rootkit if this is ever gets exploited

Michael already said that: "DRM protection"

[DeepDayze]

It sounds like the perfect place for a rootkit if this is ever gets exploited

The main aim of this is to keep rootkits and malware OUT and to protect certain data that needs protection in a secure, trusted location. This can be exploited by rootkits (via bugs) but it will be very very difficult for malware to even access this secure area (of course if this protection is implemented properly).

[DeepDayze]

Another idea is to adapt this to SSD's as well to provide a secure area much like a hidden folder or partition that is not accessible via normal filesystem access routines and is not visible in directory or partition listings. In /proc it should be indicated as a trusted block device (with whatever name the system gives it)

[c117152]

The main aim of this is to keep rootkits and malware OUT and to protect certain data that needs protection in a secure, trusted location. This can be exploited by rootkits (via bugs) but it will be very very difficult for malware to even access this secure area (of course if this protection is implemented properly).

No. It's a DRM key store. Storing trusted keys in it would be a huge mistake since you won't be able to revoke compromised keys.
Knox is a good example for real world usages: http://forum.xda-developers.com/show....php?t=2486346

[Luke]

This could be a place to stash unlocked device keys for encrypted partitions, with the downside that an opponent who can defeat the security on it would know where to look for them. I am familiar with online attacks on encryption that are trivial to an attacker who can get a root shell on your machine, this would make it much more difficult and reduce the need to rotate keys at frequent intervals. Key rotation in a large organization is a known driver of use of weak keys and even worse, of keys being written down.

The counter for DRM on personal machines is obvious: don't install any of the apps or plugins that use kernel functions or anything else to restrict your own access to media. All of them will be closed source for obvious reasons. DRM has a weakness in a way similar to iPhone's encryption vulnerability: the iPhone relies on closed source software to block exploitation of a very small and easily brute-forced keyspace. DRM relies on closed code to control the weakness of keys distributed with the media and thus accessable to an attacker. In both cases an attacker who can decompile the closed code, modify and replace it can quickly decrypt the data.

OK, a DRM application uses this kernel layer? Unless the kernel is hash-checked for a special build, anyone could patch the kernel to automatically display all keys in the console. This would be only slightly harder for a skilled programmer than it would be for me to evil-maid a copy of my own encryption system on a machine going to a known enemy. For a rootkit or an online attacker to get at my disk keys the same way, the attacker would have to either patch my running kernel or replace it for the next boot, a much harder task. If the attacker has local access he can replace the kernel, but at that point a keylogger is already easier anyway.

One axiom of encryption is this: if a running encrypted system is physically in the hands of an adversary, they are root and if they are skilled there is always a way to get the keys out, the data out, or both. No DRM application can get around this, as the media has to be decrypted on a system considered hostile. If the DRM providers don't control the kernel, they don't control any kernel function used to control keys. This is why that kind of DRM probably will stay on Windows and no matter how much certain Linux developers want to support DRM'ed content Hollywood will mostly spurn them.

[vitalif]

...In other words "thanks god Linux is free and open source"

[jacob]

...In other words "thanks god Linux is free and open source"

We must thank Microsoft, Apple and the MAFIAA for sparing no effort to promote free and open source software.

[SystemCrasher]

Sure, Intel are long term supporters of bastardized hardware, treacherous computing, hardware DRM (which is not about Rendering, unfortunately) and resorted to manufacturing of totally backdoored hardware, which does not even alows one to opt out of this nasty crap. So whom these "protections" are going to protect? Bunch of treacherous bastards, pwning those who pays them money? Its so nice to offer "protection" which then pwns users, doing nothing in absolutely best case or just being abused to put backdoors and misfeatures. Hey, wintel, you suck. Go "protect" yourself this way.