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 <luto@xxxxxxxxxxxxxx> wrote: > > > >> On Nov 25, 2018, at 10:55 AM, Dr. Greg <greg@xxxxxxxxxxxx> 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: greg@xxxxxxxxxxxx >> ------------------------------------------------------------------------------ >> "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
