In a previous post, we discussed HP Secure Platform Management provisioning via the HP Client Management Script Library. We now turn our attention to HP Sure Recover , which is a feature built on top of SPM.
Introducing HP Sure Recover
From the above link, here's the high level definition of the HP Sure Recover feature.
HP Sure Recover is a PC OS recovery solution built into the hardware and firmware that can fully recover the HP OS image without requiring that recovery software be present on the machine. HP Sure Recover supports recovery using a network connection. Some devices have additional embedded storage on the motherboard to support recovery in an offline state (not connected to a network). This configuration is called HP Sure Recover with Embedded Reimaging. The embedded storage is unique from other technologies in that it is hardware-isolated from the host operating system to disallow unauthorized change
We recommend that you consult the document for further information, and some architectural discussion.
Working with HP Sure Recover and HP Client Management Script Library
In general, the first step that needs to be accomplished is the Secure Platform Management Provisioning, that was discussed in the previous blog post. This is a prerequisite for provisioning HP Secure Recover itself. At this point, you should have both the Endorsement Key and Signing Key provisioned, and the status returned by Get-HPSecurePlatformState should be either Provisioned or ProvisioningInProgress. Mine looks something like this:
State : Provisioned
Version : 1.0
Nonce : 1582046687
FeaturesInUse : None
EndorsementKeyMod : {202, 27, 68, 121...}
SigningKeyMod : {188, 27, 167, 18...}
Next, time for a little terminology and clarifying some quirks:
HP Sure Recover uses two images, one being the image you want to apply to your system, the other being the actual runtime that brings down your image and applies it. In Sure Recover terminology, the former is the "OS" image, while the second is the "Agent" image. The agent itself is a WinRE image that uses image deployment utilities to apply a images which have been packaged and compressed as WIM (Windows Imaging Format) files. Both the agent and the OS image include signed manifests to ensure file integrity.
Creating these images are a discussion for another time, for now we'll assume you have already created them.
You do not have to provision either, but if you don't, you will be running off of the defaults published by HP on HP.COM. That may be acceptable in some cases, but in other cases you may want to use you own custom image, or at the very least bring the image into your environment.
Configuring the OS and Agent images
To configure the two images, we actually use one overloaded function, New-HPSureRecoverImageConfigurationPayload. The pattern follows the SPM pattern discussed in the previous blog post:
New-HPSureRecoverImageConfigurationPayload -SigningKeyFile ".\sk.pfx" -SigningKeyPassword test -Image OS -PublicKeyFile ".\os.pem" -username myuser -password myloginpw -url "http://my.company/path/to/image.mft" | Set-HPSecurePlatformPayload New-HPSureRecoverImageConfigurationPayload -SigningKeyFile ".\sk.pfx" -SigningKeyPassword test -Image agent -PublicKeyFile ".\re.pem" -username myuser -password myloginpw -url "http://my.company/path/to/image/directory" | Set-HPSecurePlatformPayload
P.S. Remember the warning in the previous post? Don't use this pipe approach in production! Your keys should never leave your secure server.
The library is a little confusing on how public keys are passed for image validation. There are two parameters, one being ImageKeyFile which accepts either a pfx file or a X509 public key certificate (should begin with '-----BEGIN CERTIFICATE-----'). The other is PublicKeyFile which accepts a public key (should begin with '-----BEGIN PUBLIC KEY-----). The -PublicKeyFile parameter requires library version 1.4.3, due to an endianness bug in older versions.
Also, unlike suggested in HP Sure Recover documentation for other tools, the 1.4.x library does not accept RSA public keys for the PublicKeyFile parameter currently, it requires x509 public keys. Here's an example of generating an X509 public key pem from a pfx:
openssl pkcs12 -in os.pfx -clcerts -nokeys -out os.pem -passin pass:mypfxpassword openssl x509 -inform pem -in os.pem -pubkey -noout > my-image-public-key.pem
Ok, so what did we do here?
1. We created a payload for the OS or Agent images (differentiated via the -Image parameter)
2. We signed that payload using the SPM signing key sk.pfx
3. We specified that the image should be verified by the public key os.pem (or re.pem for the Agent image). You can also use pfx format if that's what you prefer.
4. We provided a URL path to the image (and username/password, if needed). For the OS image, this is the path to the image manifest (mft) file. For the agent, it's the path to the directory where the agent resides. The URL may be http or ftp at this time.
[Updated October 2, 2020]
I realize it's not quite obvious. Here we call out two new PEM files, os.pem and re.pem. These are the public keys for the key pair that was used to sign the OS and Agent images, respectivaly, when using custom images. They are not directly related to the Endorsement (KEK) or Signing (SK) keys, but should be the keys that were used to generate the signature (.sig) file for your custom images. If you are not using a custom image for the OS or Agent, you can skip provisioning these keys.
So for example, you used "MyOsKey.pem" to sign your OS image. You could generate the public key pem via:
openssl rsa -in MyOsKey.pem -pubout -out os.pem
The resulting os.pem (or equivalent re.pem) is the one referenced in the above discussion.
Also, the username and password is vulnerable inside the generated payload. Ensure that they refer to an account that has read-only permissions to the URL path.
And a known issue: The agent (RE) signature (.sig) file must be little endian on some platforms, whereas other platforms will accept both big and little endian. If you use custom Agent images and run into problems with validating the signature of the Agent, ensure that the .sig file is in little endian format.
[End update]
Now if you were to run Get-HPSecurePlatformState, you would see HP Sure Recover as an enabled feature:
State : Provisioned
Version : 1.0
Nonce : 1582046687
FeaturesInUse : SureRecover
EndorsementKeyMod : {202, 27, 68, 121...}
SigningKeyMod : {188, 27, 167, 18...}
And if you were to check the status of HP Sure Recover (via the Get-HPSureRecoverState -All), you'd see:
Version : 1.0
Nonce : 1582049473
OsImageFlags : None
ImageIsProvisioned : True
AgentFlags : None
AgentIsProvisioned : True
RecoveryTimeBetweenRetries : 0
RecoveryNumberOfRetries : Infinite
Schedule : @{WindowSize=0; Hour=0; Minute=0; DayOfWeek=None}
ConfigurationDataIsProvisioned : False
TriggerRecoveryDataIsProvisioned : False
ScheduleRecoveryDataIsProvisioned : False
SchedulerIsDisabled : True
Image : @{Url=http://my.company/path/to/image.mft; Username=test; ProvisioningVersion=1}
Agent : @{Url=http://my.company/path/to/image/directory; Username=myuser;
ProvisioningVersion=1}
Configuring recovery schedule
Okay, so we configured our images, we can now set a schedule. Let's say we want to perform a recovery every Sunday at 2:30 am, and we'll give it a 30-minute window size for the operation to occur. We use the New-HPSureRecoverSchedulePayload function to create this payload.
New-HPSureRecoverSchedulePayload -SigningKeyFile ".\sk.pfx" -SigningKeyPassword test -DayOfWeek Sunday,EveryWeek -Hour 2 -Minute 30 -WindowSize 30 | Set-HPSecurePlatformPayload
Now if you were to re-run the Get-HPSureRecover state, you should see the schedule reflected.
Performing a recovery
In order to perform a recovery, the system needs to start off in a an off or sleeping state, or you will need to reboot the computer during the window defined in the schedule above. Alternately, if you want to perform a recovery on next reboot, without setting a schedule, you can use New-HPSureRecoverTriggerRecoveryPayload function.
Deprovisioning Sure Recover
To deprovison sure recover, you will need the SPM signing key:
New-HPSureRecoverDeprovisionPayload -SigningKeyFile ".\sk.pfx" -SigningKeyPassword test | Set-HPSecurePlatformPayload
This will remove all Sure Recover-specific keys, and erase any defined schedule. Note that you will not be able to deprovision SPM while Sure Recover (or any other feature depending on SPM) is provisioned.
Embedded Imaging Device (where available)
The embedded imaging device is available as an option on some SKUs. This is basically an aditional storage used for storing the image for recovery purposes, without relying on network or cloud services. It is of course, significantly faster than using the online recovery method. For security reasons, this storage is not accessible from Windows, and can only be accessed at specific (service) times.
To determine if the imaging device is available, refer to the Get-HPSureRecoverReimagingDeviceDetails function.
Image credit Pedro Sandrini, São Paulo, Brazil, via pexels.com