Bah, I hit send on a partially written draft. I’ll try again soon. --Andy
> On Nov 25, 2018, at 1:59 PM, Andy Lutomirski <l...@amacapital.net> wrote: > > > >> On Nov 25, 2018, at 10:55 AM, Dr. Greg <g...@enjellic.com> wrote: >> > >> >> >> The notion of a launch enclave is critical to establishing these >> guarantees. As soon as the kernel becomes involved in implementing >> SGX security policy the architecture becomes vulnerable to kernel >> and/or privilege modification attacks. >> >> We've talked at length about the provisioning bit, I won't go into >> details unless people are interested, but the EPID provisioning >> protocol implements an SGX mediated cryptographic contract that a >> perpetual platform identifier will not be disclosed to anyone but >> Intel. > > As a reviewer, and as an occasional academic cryptographer, I need to put my > foot down here. This is inaccurate. > > There is an SGX-mediated contract that says: > > 1. For any given public key p, a perpetual platform identifier ID_p exists > and will only be disclosed to the holder of the corresponding private key > p_priv or to someone to whom the private key holder permits (intentionally or > otherwise) to use that identifier. > > 2. The ability described in #1 is available to anyone whom the kernel and > launch enclave (if the MSRs are locked ) permits (intentionally or otherwise) > to use it. > > No, I have no clue why Intel did it this way. I consider it to be a mistake. > >> The launch enclave is critical to that guarantee. >> >> It is completely understandable why a locked down, (non-FLC) hardware >> platform, is undesirable in this community. That doesn't mean that a >> launch enclave as a concept is unneeded or necessarily evil. >> >> In an FLC environment the kernel assumes responsibility for SGX >> privacy and security. This means that we need to do at least as well >> with a kernel based model as to what is currently available. >> >>> There are other ways to accomplish it that might be better in some >>> respects. For example, there could be /dev/sgx and >>> /dev/sgx_rights/provision. The former exposes the whole sgx API, >>> except that it doesn???t allow provisioning by default. The latter >>> does nothing by itself. To run a provisioning enclave, you open both >>> nodes, then do something like: >>> >>> ioctl(sgx, SGX_IOC_ADD_RIGHT, sgx_provisioning); >>> >>> This requires extra syscalls, but it doesn't have the combinatorial >>> explosion problem. >> >> Here is a proposal for the driver to add the needed policy control >> that is 'SGXy' in nature. The 'SGXy' way is to use MRSIGNER values as >> the currency for security policy management. >> >> The driver should establish the equivalent of three linked lists, >> maintainable via /sysfs pseudo-files or equivalent plumbing. The >> lists are referenced by the kernel to enforce the following policies. >> >> 1.) The right to initialize an enclave without special attributes. >> >> 2.) The right to initialize an enclave with the PROVISION_KEY attribute set. >> >> 3.) The right to initialize an enclave with the LICENSE_KEY attribute set. >> >> The lists are populated with MRSIGNER values of enclaves that are >> allowed to initialize under the specified conditions. > > NAK because this is insufficient. You’re thinking of a model in which > SGX-like protection is all that’s needed. This is an inadequate model of the > real world. The attack I’m most concerned about wrt provisioning is an > attack in which an unauthorized user is permitted > > The use case I see for attestation *privacy* > >> >> The driver should either establish a 'seal' file or value, >> ie. MRSIGNER value of all zero's, that once written will not allow >> further modifications of the list(s). This will allow >> cryptographically guaranteed policies to be setup at early boot that >> will limit the ability of subsequent DAC compromises to affect policy >> management. >> >> The lists are obviously vulnerable to a kernel compromise but the >> vulnerability scope is significantly limited vs. 'can I get root or >> some other userid'. If we are really concerned about the scope of >> that vulnerability there could be an option on TPM based systems to >> verify a hash value over the lists once sealed on each enclave >> initialization. We have already conceded that EINIT isn't going to be >> any type of speed daemon. >> >> On an FLC system the driver verifies that the submitted enclave has an >> MRSIGNER value on one of the lists consistent with the attributes of >> the enclave before loading the value into the identity modulus >> signature registers. >> >> In this model, I would argue that the driver does not need to >> arbitrarily exclude launch enclaves as it does now, since the kernel >> has the ability to specify acceptable launch enclaves. The driver API >> can alaso continue to accept an EINITTOKEN which maintains >> compatibility with the current ABI. Punishment can be inflicted on >> non-FLC hardware owners by issueing EINVAL if an EINITTOKEN is >> specified on platforms with fixed launch keys. >> >> This also has the effect of allowing multiple launch enclaves at the >> platform owner's discretion. I know there was some sentiment, and >> Jarkko had code, that used a launch enclave at a fixed location such >> as /lib/firmware. That has the disadvantage of requiring that the >> kernel know about all the different ways that a launch enclave might >> be used or setup. It also establishes a cryptographic rather then a >> filesystem based guarantee on the launch enclave being used. >> >> If the lists are empty the kernel simply proceeds as it does now and >> loads any enclave submitted to it. >> >> I believe this architecture has a number of merits. It largely >> preserves compatibility with current PSW's and provides a mechanism >> for cryptographically enforced policy that is consistent with the SGX >> architecture. >> >> I need to get Christmas lights put up on the house for the squirrels >> to eat so I will leave this proposal open for debate. >> >> Have a good remainder of the weekend or whats left of it. >> >> Dr. Greg >> >> As always, >> Dr. G.W. Wettstein, Ph.D. Enjellic Systems Development, LLC. >> 4206 N. 19th Ave. Specializing in information infra-structure >> Fargo, ND 58102 development. >> PH: 701-281-1686 >> FAX: 701-281-3949 EMAIL: g...@enjellic.com >> ------------------------------------------------------------------------------ >> "Some of them are. A surprising number aren't. A personal favorite of >> mine was the log from a cracker who couldn't figure out how to untar >> and install the trojan package he'd ftped onto the machine. He tried a >> few times, and then eventually gave up and logged out." >> -- Nat Lanza
