Better a later, but well thought out pice ;-) That said, I thing we have both a fundamental philosophical difference and an issue where your and my professional opinions strongly diverge. Let me prefix that with the limitation that I am mostly talking about the general case. I will make some comments on your scenario as well. Ad 5) First, I very much believe that root not only should have access to everything, I believe it is necessary to allow reliable and secure operation of infrastructure. Sure, in the washing machine scenario (or often these days a similar "car" scenario), you do not get root access, but your service technician becomes severely limited if he does not. Then there is the little problem of incident management: If you can be locked out from things, then that is a mechanism that an attacker can use to prevent you from finding out that you were attacked in the first place and from doing anything about it. Ad 1) Your root user is remote. That is fine. But do you really need the root user to be locked out of some things in your scenario? My experience would suggest that you need to give even more power to root in this scenario, like doing a hard reset or power-cycles, not less. Ad 3) If the attacker gets root, he can just copy the decrypted disk. No need to mess with the kernel or the decryption-key at all. Or is your scenario one where you deploy the same key to multiple instances of this device and hence the key itself still offers added value after a compromise of only one of these devices? That would be bad... (See also FAQ Item 1.2 under "CLONING/IMAGING and FAQ Item 6.15) I think the threat and attack modelling needs more detail. Ad 6) I do not believe a root user can be prevented from getting access to everything on Linux. There are just to many things tied to the assumption that root can do everything and far too many holes to plug. As the same time, I do think even trying is a waste of time. What you want is a locked-down special-purpose OS that was created with the idea of root not getting full access from the ground up and including all libraries, tools, compilers, kernel and all other code. This can be done, but Linux is not the platform for it. Maybe QNX can do this, they have some "zone" concept and I expect at least two different levels of "root", one within the zone and one overall. Also, if you really need to prevent an attacker with physical access from getting the keys out of the machine then you are screwed. The only devices that can offer a reasonable assurance of that are HSMs (Hardware Security Modules) and they are $50'000 and up per piece. These are typically 19" boxes with independent power for a while, lots of sensors that detect intrusion, sturdy cases, backup mechanisms, etc. A TPM will _not_ help at all as a TPM cannot do anything itself, it has to hand out the keys for things like disk encryption to the actual, unsecured (against an attacker with hardware-access) CPU. Some more advanced HSMs can do disk encryption by themselves, and that is the only way to get disk-encryption where the key is secure against an attacker with physical access. Yes, I know that is inconvenient. But even things like secure, encrypted boot processes with (partially) secure CPUs can be hacked. Look for example at "Hacking the Xbox" by Bunny Huang or the time it takes for a new iPhone or Android version to get rooted. "Secure boot" is a fantasy on general-purpose hardware with general-purpose OSes and even mostly a fantasy on specially secured devices with "secure" hardware and fully "protected" boot process. That said, if your scanario is that you must prevent an instance compromise (single device) being equal to a group compomise, the only feasible way is to have individual keys on each device and to force the attacker to attack the keys all individually. Yes, that makes service harder, but there really seems to be no way around that at the current state of technology. I frankly do not expect the situation to get better anytime soon and it may get worse instead. On the other hand, storing a few million keys and selecting the right one when doing remote maintenance is not that hard. Then you only have to make sure the key-store on your side does not get compromised. Unless you are as terminally stupid as RSA with SecureID, this is not that hard to do either. Hell, you could have each key on a phycial card and read it in via a barcode-scanner if you need to do maintenance acceess. (Depends on the frequency of maintenance access, how many places it is being done from, how trustworthy the people doing it are, etc. There is a strong trade-off between security and convenience here.) You still need to secure the infrastructure you do access from very carefully. Probably a fully isolated network that allows only tunnels to the devices to be maintained and protects itself from attacks comming fromt thise devices is needed. And yes, none of this is cheap or simple. And forget about getting this secure without competent outside review. Gr"usse, Arno On Wed, Dec 17, 2014 at 17:22:50 CET, Ahmed, Safayet (GE Global Research) wrote: > 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 -- Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@xxxxxxxxxxx GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718 ---- A good decision is based on knowledge and not on numbers. -- Plato If it's in the news, don't worry about it. The very definition of "news" is "something that hardly ever happens." -- Bruce Schneier _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
