An embodiment is directed to switchover operations with a virtualized network device in a cloud or remote infrastructure. The virtualized hardware switchover operations may be used to selectively and temporarily provide virtualized control-plane operations to the data-plane of a non-redundant network device undergoing an upgrade or a reboot of its control plane. A non-redundant network device may operate hitless, or near hitless, operation even when its control plane is unavailable.

A multi-phase boot operation of a virtualization manager at a virtualization host is initiated at an offload card. In a first phase of the boot, a security key stored in a tamper-resistant location of the offload card is used. In a second phase, firmware programs are measured using a security module, and a first version of a virtualization coordinator is instantiated at the offload card. The first version of the virtualization coordinator obtains a different version of the virtualization coordinator and launches the different version at the offload card. Other components of the virtualization manager (such as various hypervisor components that do not run at the offload card) are launched by the different version of the virtualization controller.

Example implementations relate to custom operating system (OS) images. For example, booting a user device to a custom OS image includes presenting a user interface (UI) for creating a custom OS image for portable use, storing the custom OS image on a database for information technology (IT) management purposes, sending, based on a request, the custom OS image from the database to an secure external device, and authenticating, based on a policy, the custom OS image on the secure external device for use on a user device without an OS image or a hard drive disk (HDD).

Systems and methods are included for causing a computing device to assemble and boot from a managed operating system. When the computing device is powered on, it can execute firmware that specifies a server to contact. The server can identify an operating system (OS) to boot, and the location of a pre-enrollment installer for assembling the OS image. The pre-enrollment installer can download base OS images in one or more pieces from multiple locations determined based on ownership information of the computing device. The multiple OS images can relate to enterprise management and company-specific applications and drivers. Once the pre-enrollment installer has combined the base OS images, the computing device reboots using the combined OS image.

Methods for operating a device and for managing bootstrapping of devices are disclosed. The method (100) for operating a device comprises computing (102) a derivative of a secret shared between the device and a server entity of a network, generating (104) a temporary bootstrap URI by combining at least a part of the computed derivative with a static bootstrap URI for the network, and sending (106) a bootstrap request to the temporary bootstrap URI. The method for managing bootstrapping of devices comprises generating temporary bootstrap URIs corresponding to devices operable to connect to a network, and updating a network DNS registry to map the generated temporary bootstrap URIs to the IP address of at least one of a bootstrap server instance reachable via the network and/or a bootstrap load balancer. Also disclosed are a device, a bootstrap load balancer, a bootstrap server, and a computer program.

A UEFI client initiates an SMB negotiation with a remote server for an augmented capability protocol that supports secure distributed namespace compounding via customized commands and trusted share-specific and transaction-specific data structures, referred to herein simply as secure blobs, communicated over a secure tunnel. The client platform may include a nonvolatile storage resource containing factory-installed AC modules for both the client and the server, as well as factory stored profile information for known remote shares. Upon successfully negotiating for the AC protocol, the UEFI client may retrieve and install the AC client and server modules to enable the AC protocol. The AC client may mount a local namespace, which includes a namespace folder for each remote share. The AC server module, in combination with remote share profile information provided by the AC client, enables the remote server to mount a virtual distributed namespace and function as a RVDN server.

Boot integrity of a storage platform is verified by comparing observed boot data values with expected boot data values stored in a secure remote cloud. The boot data values include hashes of software that runs at each stage of a boot sequence, e.g., BIOS, bootloader, kernel, and runlevel programs. The observed boot data values may be provided by a TPM using an AIK and nonce. If the observed boot data values fail to match the expected boot data values then a boot integrity service running on the storage platform limits functionality such as by disabling IO services, disabling remote data replication, enabling a diagnostic service, enabling a data collection service, disabling access by non-service accounts, and protecting a management database.

A device can (i) operate a primary platform (PP) within a tamper resistant element (TRE) and (ii) receive encrypted firmware images for operating within the primary platform. The TRE can store in nonvolatile memory of the TRE (i) a PP static private key (SK-static.PP), (ii) a server public key (PK.IDS1), and (iii) a set of cryptographic parameters. The TRE can generate a one-time PKI key pair of SK-OT1.PP and PK-OT1.PP and send the public key PK-OT1.PP to a server. The TRE can receive a one-time public key from the server comprising PK-OT1.IDS1. The TRE can derive a ciphering key using an elliptic curve Diffie Hellman key exchange and the SK-static.PP, SK-OT1.PP, PK.IDS1, and PK-OT1.IDS1 keys. The TRE can decrypt the encrypted firmware using the derived ciphering key. The primary platform can comprise a smart secure platform (SSP) and the decrypted firmware can comprise a virtualized image for the primary platform.

Temporary firmware is provided as cloud services. Different temporary firmware containers are downloaded via a communications network. A light-weight operating system launches and executes the temporary firmware containers during a boot operation, POST operation, or other scheme. The temporary firmware containers thus detect and perhaps resolve POST errors. The light-weight operating system may also download a full-service/resource operating system. A second or subsequent boot operation may be performed, but control is ceded to the full-service/resource operating system. Multiple firmware tenants may thus be temporarily downloaded to a bare metal machine to support POST error detection activities. Advanced OS serviceability, diagnostics, and other containerized firmware may thus be quickly and simply launched without requiring the excessive time and difficulties of using the full-service/resource operating system.

A method is for a first-time startup of a not fully personalized secure element, which serves for the use of services of a mobile communication network, in a mobile terminal. In the method, the secure element is started and requested to transmit a status message. The secure element transmits a status message in which it is stated whether the secure element: S1) contains only a bootloader but as yet no firmware image for the secure element; S2) contains a firmware image for the secure element but is not yet fully personalized; or S3) is fully personalized. The secure element is accepted in the cases S1), S2) and S3) and rejected in other cases. In the case S1), a download for a firmware image of the secure element is initiated for a first-time startup.