[dm-crypt] Kernel Keyring Service

Ahmed, Safayet (GE Global Research) Safayet.Ahmed at ge.com
Wed Dec 17 17:22:50 CET 2014


I apologize for the delay in my reply. Thanks to everyone for the really 
informative and insightful discussion. Also, I apologize for the length of this
 e-mail, but I tried to address all the concerns that were raised.

    1 Intended Application
    2 Intended Stack
    3 One Possible Attack Scenario
    4 What I'm Interested In
    5 Should Root Be Allowed to Access Everything Including Kernel Memory?
    6 Can Root Be Prevented From Having Complete Memory Access?
    7 Levels of Protection
    8 Concerns About DRM

1 Intended Application
----------------------

My target application is an embedded system that runs without direct or 
significant user intervention like washing machines, locomotives, and power 
generators. It is possible that with time, the target platform will require 
updates to various software components. However, the administrator that has the
 ability to make persistent changes to the system is remote and not local.
 
2 Intended Stack
-----------------

For the intended application, I am considering a stack that is similar to what 
Alex mentioned. The idea is to establish a chain of trust that is rooted in 
hardware. With Intel TXT, the BIOS ACM measures the BIOS, the BIOS measures the
 BIOS configuration and boot loader. Eventually, the kernel and initramfs are 
measured. By "measured", I mean that a hash of the component is computed and 
extended into a Platform Configuration Register (PCR) in the TPM.

Similarly, Secure Boot is configured to ensure that only a trusted GRUB image 
can run, and in turn, GRUB security mechanisms are enabled to ensure that only 
signed components (kernel and initramfs image) can be loaded into memory for 
boot.

Once a trusted kernel image is up and running with the trusted kernel arguments
 and a trusted initramfs image, the kernel is responsible for protecting user 
land (I'm talking about the mechanisms similar to what is described in 
"Documentation/security/" in the kernel source. LSMs and all).
 
Stepping back, provided that the system comes up in this trusted environment, 
it should have access to the disk. If trust is not established, there should be
 no access. The trustworthiness of the environment is established through the 
PCR values mentioned earlier. So the disk-encryption key should be locked to 
PCR values in the TPM.
 
3 One Possible Attack Scenario
------------------------------

The disk-encryption key being present in kernel space is necessary and 
acceptable. I am more concerned about the key being exposed in plain text to 
user space. I disagree with the idea that the root user should have access to 
kernel memory. I address this in greater detail further below.

To understand my concerns, consider the following scenario:

    Once the system boots under a trusted configuration, if an adversary is 
    able to get root-level access from user space, this adversary can get the 
    volume key. Then, the adversary can access the disk off line from an 
    untrusted configuration. The adversary already has the volume key and 
    does not need the correct values in the PCR to access the disk. Then, the 
    disk can be accessed from any compromised configuration.
    
4 What I'm Interested In
------------------------

I am primarily interested in disk encryption through dm-crypt alone. LUKS is 
for managing the volume key with multiple user pass phrases. LUKS does not 
offer much in the use case I described above since the system is expected to 
boot without interacting with a user.

As Milan mentioned, the kernel part is independent and I don't really see why 
dm-crypt has to be tightly tied to LUKS. Instead, I would like to be able to 
pass the volume key directly to dm-crypt in kernel space and ensure that 
that key is never exposed.

As I had mentioned in a previous email, the kernel key-ring services are 
already used to import and manage keys for IMA, EVM, and ecryptfs. These 
kernel services are directly accessed through a number of system calls. 
Also you have "keyutils" to access these services from a shell. It makes sense 
to me for all keys including the dm-crypt keys to be managed through this 
single interface rather than maintaining a separate interface for dm-crypt 
keys.

5 Should Root Be Allowed to Access Everything Including Kernel Memory?
----------------------------------------------------------------------

I don't believe so. The separation between root user and non-root user is only 
a single defense mechanism. The idea that "if root is compromised, the platform
 is completely compromised" is not acceptable.
 
>From what I understand, you always see examples of arc-injection/code-injection
 attacks that allow an adversary to compromise and take over an application. 
Then, an adversary is free to pursue additional avenues for escalation of 
privilege. Even with privileged access, this access should be within the 
confines of a controlled, trusted environment.

There are already a number of mechanisms that allow the Linux kernel to be 
booted in a way that limits what root can do.  You can limit what binaries can 
be executed (even by root) with IMA appraisal. Alex already mentioned 
"capabilities" (Capcium security model). You have implementations of MAC such 
as TOMOYO and SELinux.

Given that these mechanisms are all implemented in the kernel, there should be 
a strong separation between user space and kernel space. The user should be 
able to request services from the kernel. However, the user should not be able 
to freely probe kernel memory. More importantly, the user should not be able to
 make arbitrary changes to the kernel address space.

6 Can Root Be Prevented From Having Complete Memory Access?
-----------------------------------------------------------

As Alex mentioned, the kernel can be configured to close the obvious channels 
for the root user to access kernel memory. I'm talking about disabling 
/dev/mem, /dev/kmem, /proc/kallsyms, and the like.

Ability to insert code into kernel space should also be closed off as well, by 
disabling loadable kernel modules or by requiring signed kernel modules. If 
there are non-standard channels for injecting code into the kernel like kernel 
exploits, that is something that will need to be addressed as well. (If you 
know of projects dealing with this, I am extremely interested).

As for cold-boot or reset attacks, TXT actually handles that. Specifically, on 
TXT-enabled systems, the firmware is supposed to detect reset attacks and scrub
the memory for you. There is a special "Secrets" flag that is set by the OS to
indicate that there are secrets stored in memory. During a graceful shut-down, 
this flag is reset. In the case of a reset attack, the flag is not reset. In 
that case, a component called the BIOS ACM clears the memory or assures that 
the BIOS scrubs the memory. This mechanism can be a bit more complicated and
described in greater detail in this book:

http://www.apress.com/9781430261483

Whether or not this is actually enabled with tboot/Linux and how it is used, I 
don't know.

Lastly, with coming technologies like Software Guard Extensions from Intel, it 
should become safer to store secrets in memory. From what I understand, you 
would even be able to prevent the kernel from freely probing user memory. 

7 Levels of Protection
---------------------

Physical access has different levels.
0)  You are at the mouse and keyboard of the system
1)  You can insert a USB thumb drive
2)  You can power cycle the system
3)  You can open the box and reset the pin to reset the BIOS password
4)  You can take out the disk and stick it into another machine and perform 
    some form of modification or forensics.
5)  You can probe the system memory externally at run time with a debugger
6)  You can do differential power analysis on the hardware
7)  You can take any chip apart and analyze it with an electron microscope. 
    (I've been told that this is something people actually do.)

Each additional level of access requires more time and more cost. Just because 
you can't protect against level-7 access, doesn't mean you don't try to protect
 against a level-4 access.

As Alex mentioned, there is a cost-benefit equation at play here. For an 
embedded application that is performing a critical task that does not require 
the same level of flexibility as a personal computer, a more locked-down 
configuration is acceptable if it can help protect against threats at a greater
 access level. In some cases, it might be more acceptable for all data to be 
lost and for the system to become bricked and unbootable than for the system 
to remain intact and under the control of an adversary.

8 Concerns About DRM
---------------------	

I use Linux on my personal laptop and I appreciate Arno's concerns about DRM. 
When I buy a computer, I expect to completely own that computer and decide what
 runs on it. The idea that the OEM and software provider can collude and 
connive to keep me from doing anything with my computer is absolutely 
disgusting to me. I buy it, I own it, I do whatever the hey I want with it.
 
That being said, I don't really have similar expectations about appliances like
 washing machines, TVs, or cars. (I'm pretty sure I'll void the warranties if I
 attempted to install Linux on them ;) )
 
----------------------

Thank you for taking the time to read this far. I would appreciate your 
feedback, suggestions, and thoughts.

regards,

Safayet

-----Original Message-----
From: Milan Broz [mailto:gmazyland at gmail.com] 
Sent: Sunday, December 14, 2014 1:10 PM
To: Ahmed, Safayet (GE Global Research); dm-crypt at saout.de
Subject: Re: [dm-crypt] Kernel Keyring Service

Hi,

On 12/12/2014 05:23 PM, Ahmed, Safayet (GE Global Research) wrote:
> 
> Is there a way to setup an encrypted partition with keys from the 
> kernel key ring? The key-ring services support special keys called 
> encrypted keys. These keys never exist outside kernel memory in an 
> un-encrypted state. These encrypted keys are encrypted with other keys 
> in the kernel keyring: user keys and trusted keys. Trusted keys are 
> keys protected by a TPM SRK.

...

As Alasdair said, this was discussed long time ago but never realized.

(Please do not forget that main FDE threat model is covering offline system only and there are a lot of other attack vectors.
If we allow attacker tampering with hw or access the system on administrator level nothing will help here.) 

But what storing key in keyring solves now? There are still issues

1) Key is still "open" in kernel memory just elsewhere

In current system the key resides in memory directly, not only in dmcrypt but also in all crypto API providers (it must be there if the encryption is done by CPU).

Removing key from dmcrypt structure is possible but with crypto provider it is not so easy.

So to make it at least some sense you have to use some crypto provider system which does not store key in memory.

No such generic provider is in upstream kernel.

(We are talking about designs like TreVisor/TRESOR, Loop amnesia and similar.
These will be never usable for generic configurations and architectures.)

2) Key must be transferred anyway

Currently the key is sent into dmcrypt in plain form in ioctl and only root can do this. This path was audited and properly wipes all buffers once the key is not needed.
(And yes, this is not coolest design but it is simple.)

Replacing it with transfer from kernel keyring will just move this inside kernel but removes the KISS principle here.

(On the other side, if we have one day non-root private device-mapper devices, keyring could help to properly isolate keys among users of these private dmcrypt devices.)

3) We do not have proper userspace support

If you see how the LUKS is designed, it processes volume key in userspace decrypted from keyslot. So it means redesigning keyslot operations.
(At least it means to add another level of key-hierarchy which covers keyring operations with "encrypted keys".)

I would like to see that instead of keyslots we have configurable key references (IOW it stores some unique ID of key stored in some token, keyring or whatever instead of directly encrypted volume key).
But we do not have such system yet.

I know that kernel part is kind of independent to this but without thinking how to integrate it to LUKS it does not make much sense.


So, I think using keyring is doable but I do not see it as a thing which primarily improves security.

I see it as logic separation of functions instead (keyring handles keys, dmcrypt block encryption). And as such it should be implemented one day.

Thanks,
Milan


More information about the dm-crypt mailing list