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@xxxxxxxxx]
Sent: Sunday, December 14, 2014 1:10 PM
To: Ahmed, Safayet (GE Global Research); dm-crypt@xxxxxxxx
Subject: Re: 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
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
