Hypervisor SIB Trust Chain for Secure Custom Software Installation
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Users desire to add custom binaries and configurations to a hypervisor while maintaining security features that prevent execution of unsigned software, but existing hypervisors restrict such customizations.
Innovation Solution
A method involving the use of self-signed digital certificates and vendor-trusted certificates to verify and install custom software installation bundles (SIBs) in a hypervisor, allowing users to create and install custom SIBs while ensuring security through trusted digital signatures.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If the hypervisor enforces security features to prevent execution of unsigned binaries and scripts, then security is improved, but the ability to install custom software installation bundles (SIBs) is restricted
Solution Approach 1:
The patent introduces a certificate store as an intermediary component that stores trusted certificates. When a user wants to install a custom SIB, the system verifies the digital signature against certificates in the certificate store. This intermediary mechanism allows custom SIBs to be installed while maintaining security, as the certificate store acts as a trusted mediator between user customizations and the security enforcement mechanism.
Solution Approach 2:
The patent changes the parameter of trust verification by allowing the certificate store to be populated with trusted certificates through signed operations. Instead of requiring all custom SIBs to have vendor signatures, the system changes the verification parameter to accept signatures from any source whose certificate is trusted in the certificate store. This parameter change enables customization flexibility while maintaining security through the trusted certificate mechanism.
2Reliability
If the hypervisor prevents execution of binaries and scripts not from signed SIBs, then security is improved, but user ability to add custom binaries and scripts is reduced
Solution Approach 1:
The certificate store serves as an intermediary that mediates between security requirements and user customization needs. Users can add custom binaries and scripts by creating SIBs with digital signatures. The system verifies these signatures against the certificate store, which contains trusted certificates. This intermediary mechanism enables users to easily customize the hypervisor while maintaining security through the trusted certificate verification process.
Solution Approach 2:
The patent enables self-service customization by allowing users to create and sign their own SIBs with their private keys. Users can independently add custom binaries, scripts, and configurations without requiring vendor intervention. The certificate store, populated through signed operations, enables users to self-manage their customizations while the security mechanism automatically verifies trust through the established certificate infrastructure.
3Reliability
If the hypervisor prevents some post-boot configurations, then security is improved, but the ability to apply desired configurations is limited
Solution Approach 1:
The patent changes the configuration verification parameter from requiring vendor signatures to accepting signatures from trusted certificates in the certificate store. This parameter change allows post-boot configurations to be applied flexibly while maintaining security. The certificate store, populated through signed operations, enables the system to verify trust for configuration changes without restricting configuration flexibility. Users can apply desired configurations through SIBs that are verified against the trusted certificate mechanism.
Data Source
AI summary
An example method of installing a first software installation bundle (SIB) in a hypervisor of a computer includes: receiving, by the hypervisor, the first SIB, the first SIB having a first digital signature created using a first public-private key pair and a first certificate created using the first public-private key pair; receiving, by the hypervisor, a second SIB, the second SIB having a payload being the first certificate, the second SIB having a second digital signature created using a second public-private key pair and a second certificate created using the second public-private key pair; installing, by the hypervisor, the second SIB by verifying the second digital signature and adding the first certificate to a key store of the hypervisor; and installing, by the hypervisor, the first SIB by verifying trust of the first certificate in the key store and verifying the first digital signature.