Abstract: The present disclosure is directed to secure sensor data transport and processing. End-to-end security may prevent attackers from altering data during the sensor-based security procedure. For example, following sensor data capture execution in a device may be temporarily suspended. During the suspension of execution, sensor interface circuitry in the device may copy the sensor data from a memory location associated with the sensor to a trusted execution environment (TEE) within the device. The TEE may provide a secure location in which the sensor data may be processed and a determination may be made as to whether to grant access to the secure resources. The TEE may comprise, for example, match circuitry to compare the sensor data to previously captured sensor data for users that are allowed to access the secured resources and output circuitry to grant access to the secured resources or to perform activities associated with a security exception.

Abstract: An embodiment includes an apparatus comprising: an out-of-band cryptoprocessor coupled to secure non-volatile storage; and at least one storage medium having firmware instructions stored thereon for causing, during runtime and after an operating system for the apparatus has booted, the cryptoprocessor to (a) store a key within the secure non-volatile storage, (b) sign an object with the key, while the key is within the cryptoprocessor, to produce a signature, and (c) verify the signature. Other embodiments are described herein.

Abstract: Embodiments related to hardware configuration reporting and arbitration are disclosed herein. For example, an apparatus for hardware configuration reporting may include: a processing device having a trusted execution environment (TEE) and a non-trusted execution environment (non-TEE); request service logic, stored in the memory, to operate within the TEE to receive an indication of a request from arbiter logic, wherein the request represents a hardware configuration register; and reporting logic, stored in the memory, to operate within the TEE and to report an indicator of a value of the hardware configuration register represented by the request to the arbiter logic. Other embodiments may be disclosed and/or claimed.

Abstract: Systems, apparatuses and methods may provide for receiving, from a host driver, factory data including one or more of calibration data, platform identifier data, manufacturer data or wireless carrier data, and verifying integrity of the factory data. Additionally, the factory data may be provisioned into non-volatile memory (NVM) in accordance with an operating system independent format managed by a platform root-of-trust such as a Trusted Execution Environment (TEE). In one example, provisioning the factory data includes defining one or more partitions in the NVM, initiating storage of the factory data to the NVM along the one or more partitions, and specifying a restriction profile for the one or more partitions, wherein the restriction profile includes one or more of read restrictions, write restrictions, time bound restrictions or location bound restrictions.

Abstract: Technologies for configuring a launch enclave include a computing device having a processor with secure enclave support. A trusted execution environment (TEE) of the computing device stores a launch enclave hash in a launch enclave hash table in secure storage and provisions the launch enclave hash to platform firmware at runtime. The TEE may receive the launch enclave hash via trusted I/O. The platform firmware sets a configure enclave launch bit and resets the computing device. On reset, the TEE determines whether the launch enclave hash is allowed for launch. The TEE may evaluate one or more launch configuration policies and may select a launch enclave hash based on the launch configuration policies. If allowed, the platform firmware writes the launch enclave hash to a model-specific register of the processor, and the launch enclave may be loaded and verified with the launch enclave hash. Other embodiments are described and claimed.

Abstract: The present disclosure is directed to firmware block dispatch based on fusing. A device may determine firmware blocks to load during initialization of the device based on fuses set in a processing module in the device. A firmware module may comprise at least a nonvolatile (NV) memory including boot code and a firmware information table (FIT). During initialization the boot code may cause the processing module to read fuse information from a fuse module and to determine at least one firmware block to load based on the fuse information. For example, the fuse information may comprise a fuse string and the processing module may compare the fuse string to the FIT table, determine at least one pointer in the FIT table associated with the fuse string and load at least one firmware block based on a location (e.g., offset) in the NV memory identified by the at least one pointer.

Abstract: The present disclosure is directed to content protection for Data as a Service (DaaS). A device may receive encrypted data from a content provider via DaaS, the encrypted data comprising at least content for presentation on the device. For example, the content provider may utilize a secure multiplex transform (SMT) module in a trusted execution environment (TEE) module to generate encoded data from the content and digital rights management (DRM) data and to generate the encrypted data from the encoded data. The device may also comprise a TEE module including a secure demultiplex transform (SDT) module to decrypt the encoded data from the encrypted data and to decode the content and DRM data from the encoded data. The SMT and SDT modules may interact via a secure communication session to validate security, distribute decryption key(s), etc. In one embodiment, a trust broker may perform TEE module validation and key distribution.

Abstract: Methods, systems and storage media are disclosed for enhanced system boot processing that authenticates boot code based on biometric information of the user before loading the boot code to system memory. For at least some embodiments, the biometric authentication augments authentication of boot code based on a unique platform identifier. The enhanced boot code authentication occurs before loading of the operating system, and may be performed during a Unified Extensible Firmware Interface (UEFI) boot sequence. Other embodiments are described and claimed.

Abstract: In one embodiment, a method is provided that may include one or more operations. One of these operations may include, in response, at least in part, to a request to store input data in storage, encrypting, based least in part upon one or more keys, the input data to generate output data to store in the storage. The one or more keys may be authorized by a remote authority. Alternatively or additionally, another of these operations may include, in response, at least in part, to a request to retrieve the input data from the storage, decrypting, based at least in part upon the at least one key, the output data.

Abstract: Technologies for fast low-power startup include a computing device with a processor having a power management integrated circuit. The computing device initializes platform components into a low-power state and determines, in a pre-boot firmware environment, the battery state of the computing device. The computing device determines a minimum-power startup (MPS) configuration that identifies platform components to be energized and determines whether the battery state is sufficient for the MPS configuration. If sufficient, the computing device energizes the platform components of the MPS configuration and boots into an MPS boot mode. In the MPS boot mode, the computing device may execute one or more user-configured application(s). If the battery state is sufficient for normal operation, the computing device may boot into a normal mode. In the normal mode, the user may configure the MPS configuration by selecting features for the future MPS boot mode. Other embodiments are described and claimed.

Abstract: Technologies for secure mediated reality content publishing includes one or more mediated reality servers, multiple mediated reality listeners, and multiple mediated reality creators. The mediated reality server performs an attestation procedure with each listener based on a pre-provisioned attestation credential of that listener and provisions a session encryption key to each validated listener. The attestation procedure may validate a trusted execution environment of each listener. The mediated reality server generates aggregated mediated reality content based on protected mediated reality content received from the creators and generates an associated license that defines one or more content usage restrictions of the aggregated mediated reality content. The server sends the aggregated mediated reality content to the listeners, protected by the corresponding session encryption key.

Abstract: Methods and apparatus to increase cloud availability and silicon isolation using secure enclaves. A compute platform is configured to host a compute domain in which a plurality of secure enclaves are implemented. In conjunction with creating and deploying secure enclaves, mapping information is generated that maps the secure enclaves to platform/CPU resources, such as Intellectual Property blocks (IP) belong to the secure enclaves. In response to platform error events caused by errant platform/CPU resources, the secure enclave(s) belonging to the errant platform/CPU are identified via the mapping information, and an interrupt is directed to that/those secure enclave(s). In response to the interrupt, a secure enclave may be configured to one or more of handle the error, pass information to another secure enclave, and teardown the enclave. The secure enclave may execute an interrupt service routine that causes the errant platform/CPU resource to reset without resetting the entire platform or CPU, as applicable.

Abstract: An embodiment includes an apparatus comprising: an out-of-band cryptoprocessor coupled to secure non-volatile storage; and at least one storage medium having firmware instructions stored thereon for causing, during runtime and after an operating system for the apparatus has booted, the cryptoprocessor to (a) store a key within the secure non-volatile storage, (b) sign an object with the key, while the key is within the cryptoprocessor, to produce a signature, and (c) verify the signature. Other embodiments are described herein.

Abstract: In one embodiment, a system includes: a processor; a security processor to execute in a trusted executed environment (TEE), the security processor to execute memory reference code (MRC) stored in a secure storage of the TEE to train a memory coupled to the processor; and the memory coupled to the processor. Other embodiments are described and claimed.

Abstract: Various embodiments are generally directed to an apparatus, method and other techniques for allocating a portion of the memory as system management random access memory (SMRAM) including a system management interrupt (SMI) handler for a system management mode (SMM), the SMI handler to handle SMIs for the SMM, generating a page table for the SMM, the page table comprising one or more mapped pages to map virtual addresses to physical addresses for the SMM, and setting one or more page table attributes for the page table to prevent a malicious code attack on the SMM.

Abstract: Embodiments of multinode hubs for trust operations are disclosed herein. In some embodiments, a multinode hub may include a plurality of memory regions, a trapping module, and a trusted platform module (TPM) component. Each memory region may be associated with and receive trust operation data from a coherent computing node. The trapping module may generate trap notifications in response to accesses to the plurality of memory regions by the associated coherent computing nodes. The trap notifications may indicate which of the plurality of memory locations has been accessed, and the TPM component may process the trust operation data in a memory region indicated by a trap notification. Other embodiments may be disclosed and/or claimed.

Abstract: Technologies for performing a secure firmware update include a compute device that includes a memory device to store firmware update payload, one or more devices that have direct memory access (DMA) to the memory, a DMA remap module, and a firmware update module. The DMA remap module is to create a memory isolation domain for each of the one or more devices. Each memory isolation domain comprises a physical address space in the memory that is mutually exclusive to the physical address spaces of the other memory isolation domains. The firmware update module is to (i) analyze the firmware update payload to identify one or more of the devices associated with the firmware update payload and (ii) move the firmware update payload to the memory isolation domains of each associated device to enable secure transmission of the firmware update payload to the associated devices.

Abstract: Systems and methods may provide for identifying a runtime behavioral pattern of an application and detecting an anomaly in the runtime behavioral pattern. In addition, a security event may be triggered in response to the anomaly. In one example, the anomaly is detected with regard to one or more of a library call count, a library call type, a library call argument configuration or a library call timing associated with a runtime operation of the application.

Abstract: The present disclosure is directed to secure sensor data transport and processing. End-to-end security may prevent attackers from altering data during the sensor-based security procedure. For example, following sensor data capture execution in a device may be temporarily suspended. During the suspension of execution, sensor interface circuitry in the device may copy the sensor data from a memory location associated with the sensor to a trusted execution environment (TEE) within the device. The TEE may provide a secure location in which the sensor data may be processed and a determination may be made as to whether to grant access to the secure resources. The TEE may comprise, for example, match circuitry to compare the sensor data to previously captured sensor data for users that are allowed to access the secured resources and output circuitry to grant access to the secured resources or to perform activities associated with a security exception.

Abstract: Apparatuses, methods and storage medium associated with reverse DRM geo-fencing are disclosed. In embodiments, an UAV may comprise sensors to provide sensor data for aerial operation over or near a geographic area, and collect sensor data of a target within the geographic area, and a reverse DRM geo-fence policy enforcement manager to enforce reverse DRM geo-fence policies on operation of the sensors while the UAV operates over/near the geographic area. In other embodiments, a base station may include a reverse DRM geo-fence policy generator to instruct an UAV to enforce reverse DRM geo-fence policies on operation of sensors of the UAV on collecting sensor data of the target within the geographic area while the UAV operates over or near the geographic area. Other embodiments may be disclosed or claimed.