Abstract: A trusted execution environment (TEE) of a computing device may receive an operation request requiring use of a protected data accessible only to the TEE. Responsive to receiving the operation request, the TEE may generate first data. The computing device may send the first data to a remote computing device. Responsive to sending the first data, the TEE may receive second data. The TEE may validate the second data to verify the remote computing device generated the second data. Responsive to validating the second data was generated by the remote computing device, the TEE may perform the requested operation using the protected data.

Abstract: The method of authenticating the source of a communication is disclosed. The method includes executing a clock for an operation period. The method also includes receiving a communication from a remote device at a communication time corresponding to a time interval of a plurality of time intervals sequentially covering the operation period. Each time interval has an associated authentication value. The communication includes a commitment value. The method also includes determining whether the commitment value matches the authentication value associated with the time interval corresponding to the communication time. The method also includes processing the communication when the commitment value matches the authentication value associated with the time interval corresponding to the communication time.

Abstract: Described is a process for securely authorizing access to media content from a first device to a second device. Access to content may be authorized by performing authentication from the first device. Information used for authentication (e.g. login information) is not shared with the second device. Instead, a token may be used to authenticate the second device. The authorization process may be done in a secure manner by sharing only the generated token with the second device. Authentication information may not be derived from the token, and accordingly, even if the second device is not secure or the token is exposed, authentication information remains secure.

Abstract: A user-provided keystore may be utilized in a boot process to verify a boot image as disclosed herein. A device may be determined to be in a locked or verified state. A selected keystore may be determined to not verify against a first key such as a root key. A user may provide a keystore to a device. The system may display a prompt to the user which asks whether the user would like to continue to boot or not, if the system determines that the keystore does not verify against the first key. The user may respond to the prompt by indicating a desire to continue booting. The system may determine that the boot image verifies against the keystore and finish booting the device. Thus, the prompt may alert the user to a threat to the integrity of the boot process or device.

Abstract: A trusted execution environment (TEE) of a computing device may receive an operation request requiring use of a protected data accessible only to the TEE. Responsive to receiving the operation request, the TEE may generate first data. The computing device may send the first data to a remote computing device. Responsive to sending the first data, the TEE may receive second data. The TEE may validate the second data to verify the remote computing device generated the second data. Responsive to validating the second data was generated by the remote computing device, the TEE may perform the requested operation using the protected data.

Abstract: The method of authenticating the source of a communication is disclosed. The method includes executing a clock for an operation period. The method also includes receiving a communication from a remote device at a communication time corresponding to a time interval of a plurality of time intervals sequentially covering the operation period. Each time interval has an associated authentication value. The communication includes a commitment value. The method also includes determining whether the commitment value matches the authentication value associated with the time interval corresponding to the communication time. The method also includes processing the communication when the commitment value matches the authentication value associated with the time interval corresponding to the communication time.

Abstract: Described is a process for securely authorizing access to media content from a first device to a second device. Access to content may be authorized by performing authentication from the first device. Information used for authentication (e.g. login information) is not shared with the second device. Instead, a token may be used to authenticate the second device. The authorization process may be done in a secure manner by sharing only the generated token with the second device. Authentication information may not be derived from the token, and accordingly, even if the second device is not secure or the token is exposed, authentication information remains secure.

Abstract: A method for updating configuration information includes, in a computing device including a processor, memory, and an operating system, initiating an update to at least one configuration setting of the computing device. The update may be downloaded from at least one update data source. The update may include configuration update data and configuration update metadata. The update may be verified by comparing the configuration update metadata with metadata associated with a current version of the at least one configuration setting. The update may be installed if it is verified. The update to the at least one configuration setting may be installed based on an intent from an unsecure component of the computing device. The unsecure component may include content consuming application installed on the device, a component of a computing platform of the device, and/or an update-seeker application installed on the device.

Abstract: A user-provided keystore may be utilized in a boot process to verify a boot image as disclosed herein. A device may be determined to be in a locked or verified state. A selected keystore may be determined to not verify against a first key such as a root key. A user may provide a keystore to a device. The system may display a prompt to the user which asks whether the user would like to continue to boot or not, if the system determines that the keystore does not verify against the first key. The user may respond to the prompt by indicating a desire to continue booting. The system may determine that the boot image verifies against the keystore and finish booting the device. Thus, the prompt may alert the user to a threat to the integrity of the boot process or device.

Abstract: A method may include, in a computing device including a processor, memory, an operating system, and at least one installed application, detecting an attempted exploitation of at least one known vulnerability associated with the device. The attempted exploitation may be logged. At least one remedial action may be performed on the device based on the logged attempted exploitation. The known vulnerability may be associated with the operating system and/or the at least one installed application. The at least one known vulnerability may include one or more of at least one known coding flaw in the operating system or in the at least one installed application, at least one known weakness in a protocol running on the computing device, a known family of coding flaws in the operating system or in the at least one installed application, an unauthorized triggering of premium SMS services, and/or triggering of a hostile misconfiguration.

Abstract: A method may include, in a computing device including a processor, memory, an operating system, and at least one installed application, detecting an attempted exploitation of at least one known vulnerability associated with the device. The attempted exploitation may be logged. At least one remedial action may be performed on the device based on the logged attempted exploitation. The known vulnerability may be associated with the operating system and/or the at least one installed application. The at least one known vulnerability may include one or more of at least one known coding flaw in the operating system or in the at least one installed application, at least one known weakness in a protocol running on the computing device, a known family of coding flaws in the operating system or in the at least one installed application, an unauthorized triggering of premium SMS services, and/or triggering of a hostile misconfiguration.

Abstract: A method for updating configuration information includes, in a computing device including a processor, memory, and an operating system, initiating an update to at least one configuration setting of the computing device. The update may be downloaded from at least one update data source. The update may include configuration update data and configuration update metadata. The update may be verified by comparing the configuration update metadata with metadata associated with a current version of the at least one configuration setting. The update may be installed if it is verified. The update to the at least one configuration setting may be installed based on an intent from an unsecure component of the computing device. The unsecure component may include content consuming application installed on the device, a component of a computing platform of the device, and/or an update-seeker application installed on the device.

Abstract: An application distribution server may be operable to perform an application distribution process for an application, where the application distribution process may comprise a plurality of phases. The plurality of phases may comprise, in sequence, a developer account creation phase, a risk assessment phase, an application upload phase, an application publication phase, an application promotion phase and an application download phase. The application distribution server may detect, at each of the plurality of phases, whether a particular behavior corresponding to use of the application to distribute undesirable software may occur. In instances when an occurrence of the particular behavior is detected at a certain phase in the application distribution process, the application distribution server may continue, utilizing a trap system, one or more subsequent phases after the certain phase for the application, without communicating information on the detection of the occurrence of the particular behavior.

Abstract: Systems, methods, routines and/or techniques for time delay on services (e.g., verification services) that detect undesirable content are described. In some embodiments, a flexible verification service prevents users (e.g., hackers) from using the verification service “as an oracle” to predict whether the user's application or software program will be detected by the verification service. The verification service, after receiving a verification request from a client device, may delay or prevent the communication of a verification response to the client device. The verification service may evaluate a verification request to determine a level of risk associated with the request. The verification service may communicate an initial response to the client device that submitted the verification request. The verification service may eventually communicate the verification response to the client device, for example, after a period of delay.