Product
Definition of a Product in the LAAVAT Platform¶
A Product in the LAAVAT platform is a configuration to manage cryptographic keys, PKI, and operations like image signing, that are needed to enable embedded security features such as secure boot, firmware updates, and strong device identities. For device developers, it maps to a specific device requiring these security features or a use case, like Windows signing.
Current Limitations with the Product concept:
- Product cannot have AHAB tree and HAB tree in one product definition.
- Self signed End-Entity code signing certificates are not supported.
- Currently issuing generic certificates from a CA is not supported. They are tied to a use case.
A Few Product Examples¶
| Use Case | Product in LAAVAT Platform | Product Component |
|---|---|---|
| Secure device identities for IoT devices: A manufacturer wants to enable secure identities for their IoT devices. | A product to manage cryptographic keys and PKI for secure device identities. |
|
| Secure boot and device identities for IoT devices: A manufacturer wants to enable secure boot and secure device identities for their embedded devices. | A product to manage cryptographic keys, PKI, and image signing for secure boot and device identities. |
|
| The product is used to sign Windows binaries, enabling a manufacturer to distribute Windows-based software while verifying its origin. | A product to manage cryptographic key and PKI needed for Windows signing. |
|
Product datastructure¶
- Product General Info: Specifies the name, description, and other details of the Product.
- CAInfo Section: Defines the PKI hierarchy, if required.
- Product Configuration Items: Lists possible configuration items for the Product. Some are provided during initial Product definition, while others are generated during Product creation.
- RnD Keys Section: Allows the addition of RnD keys for the Product (currently unused).
- Product Operations: Includes the name, operation type, optional cryptographic token, and approval rule for each operation.
Some items are sensitive and not shown in the Product definition; they can only be retrieved by authorized users (see the Clients section). Products are created using JSON templates or programmatically. All examples in this documentation use JSON.
Product general info¶
Product general info contains the unique name of the product. There can be only one product with the given name.
Product CA section¶
PKI is defined in more detail in the PKI chapter
Product configuration¶
A list of product configuration can be provided when creating a product. Also product creation may create additional config items which can then be used e.g., by Manufacturing.
Currently supported configuration items:
| Config item name | Config item value | Notes | Generated by the system |
|---|---|---|---|
| SRKHash | SRK hash in Base64 encoded bytes SRK hash | Returned in created product. Only generated if product contains (A)HAB tree | true |
| SRKTable | SRK Table in Base64 encoded format | Returned in created product. Only generated if product contains (A)HAB tree | true |
| EFusePPKBits | Base64 encoded bytes for PPK bits | Returned in created product. Only generated if product contains operation to create keys for Zynq based products | true |
| KEK-IVCustomEncryption | Base64 encoded bytes | Returned in created product. Used only Custom encryption operation is used. Please contact support@laavat.io for further details | true |
| FusemapType |
|
Provided when creating the product | false |
| RegistryURL | Input value for OCI signing | Only used if production operation with type SignOCI is present e.g., 1111122222.dkr.ecr.eu-west-1.amazonaws.com | false |
More information about FusemapType
| FusemapType | Description |
|---|---|
| IMXAHAB | Creates SRKHash and SRK table as with srktool --ahab_ver --sign_digest sha384 --table table.bin --efuses fuses.bin --certs srk1_crt.pem,srk2_crt.pem,srk3_crt.pem,srk4_crt.pem |
| IMX6, | Creates SRKHash and SRK table as with srktool --hab_ver 4 --table table.bin --efuses fuses.bin --digest sha256 --certs srk1_crt.pem,srk2_crt.pem,srk3_crt.pem,srk4_crt.pem |
| IMX6vS | Custom use case. Please contact support@laavat.io for further details |
| IMX8 | Creates SRKHash and SRK table as with srktool --hab_ver 4 --table table.bin --efuses fuses.bin --digest sha256 --certs srk1_crt.pem,srk2_crt.pem,srk3_crt.pem,srk4_crt.pem |
| IMX8vS | Custom use case. Please contact support@laavat.io for further details |
Product operations¶
Different operation types¶
| Operation | Description | Additional info |
|---|---|---|
| DetachedSignature | Signs the digest with EndEntity private key | |
| DigestSigning | Signs the digest with the associated private key | Token is created within the operation |
| IssueDeviceCertificate | Issues Device certificate from the Device CA defined for the product | |
| RaucBundleSigning | Signs/encrypts the RAUC payload | |
| SignAHAB | Signs digest using AHAB tree | Returns CMS formatted payload |
| SignHABCSF | Signs digest using HAB tree CSF key | Returns CMS formatted payload |
| SignHABIMG | Signs digest using HAB tree IMG key | Returns CMS formatted payload |
| SignHAB | Performs cst signing using the (A)HAB tree | Returns signed payload. Used with i.MX6-9 |
| SignJAVA | Signs JAVA/JAR packages with the Endentity key and associated certificate | |
| SignKernel | Signs the digest with the associated private key | |
| SignOCI | OCI signs the containers with the associated private key | |
| SignUBoot | Signs the digest with the associated private key | |
| SignWindowsBinary | Signs Windows packages with the Endentity key and associated certificate |
Tokens for operation¶
For some operations Cryptographic tokens are required to perform the operation. E.g., a digest signing operation may require a RSA key pair can have RSA key associated with it. In this case, the operation owns the private key and it publishes the public part. The tokens are created when product is created. Some signing operations may rely on a PKI hierarchy. In that case their token information is empty
Approval rules¶
Approval rules control who can perform the product operation e.g., creating a signing request, who can approve such a request, and if there is an automatic approval enabled (blanket groups). These rules are per operation for a product.
If the requestor is also a member in some of the groups defined in blanketGroups, then no approval is required e.g., Jenkins usage.
Group IDs for the selected enterprise identity platform are created and then populated with the relevant entities. Then the Object IDs of those groups are then used in the relevant places in the Approval Rule.
See example below:
- There are two groups ("7911d74f-bda6-4fb0-9167-ba298e5df550", "7911d74f-bda6-4fb0-9167-ba298e5df551"). The entities in these groups can make a request.
- The approval is handled by the persons belonging to the "7911d74f-bda6-4fb0-9167-ba298e5df552" group.
- If the requestor who made the request belongs to group "7911d74f-bda6-4fb0-9167-ba298e5df550" then the request is autoapproved.
"approvalRule": {
"name": "Some descriptive name",
"description": "More information about the rule",
"allowedGroups": [
"7911d74f-bda6-4fb0-9167-ba298e5df550",
"7911d74f-bda6-4fb0-9167-ba298e5df551"
],
"approvalGroups": [
"7911d74f-bda6-4fb0-9167-ba298e5df552"
],
"blanketGroups": [
"7911d74f-bda6-4fb0-9167-ba298e5df550"
]
}
It needs to be carefully planned who are allowed to make requests to a product, if there is approval needed and if there who are the correct persons who can approve.
Product creation¶
The product is first defined and then submitted to the Solution. The product requires approval before any of the keys are created.
Once approved, the creation of the needed resources starts. The creation time depends on how many keys are needed and usually takes a couple of minutes. Once the product is ready, the operations can be used, and further configuration can be done (e.g., adding clients for retrieving sensitive information from the product).
Examples of products¶
Profile YAML file examples are available in the reference client package. Contact support@laavat.io for the package.
Gateway Product with support for digest signing¶
Product only consists of one product operation Digest signing with defined approval rule. This product would create one 2048-bit RSA keypair to the CloudHSM.
{
"name": "$PRODUCTNAME",
"description": "Product gateway",
"productType": "Production",
"enabled": true,
"caInfo": [],
"rndKeys": [],
"productOperations": [
{
"name": "Digest signing",
"description": "RSA key for digest signing",
"operationType": "DigestSigning",
"token": {
"name": "1002300",
"description": "Digest signing key gateway",
"keyType": "RSA2048"
},
"approvalRule": {
"name": "Rule for access",
"description": "Rule used for testing",
"allowedGroups": [
"$WRITERGROUP"
],
"approvalGroups": [
"$APPROVERGROUP"
],
"blanketGroups": [
"$WRITERGROUP"
]
}
}
]
}
i.MX6 based gateway product¶
The product consists of the HAB hierarchy and three product operations.
Create a PKI profile before product creation. Check a chapter Examples of profiles from the PKI for example HAB templates. ProfileIDs must be replaced with the profile IDs defined in the system as described in the PKI chapter.
- FIT image (re)signing with two possible operations (Kernel and U-Boot)
- SignHAB operation which uses CST tool. Uses SRK0->CSF0 and SRK0->IMG0 keys.
This product generates twelve 4096-bit RSA key pairs and two 2048-bit key pairs to the CloudHSM.
{
"name": "$PRODUCTNAME",
"description": "TEST Product for i.MX6 based product",
"productType": "Production",
"enabled": true,
"caInfo": [
{
"CN": "SRK0",
"description": "CA used for i.MX6 HAB",
"useCase": "HABCA",
"profileID": "$ROOTPROFILEID",
"keyType": "RSA4096",
"certificateType": "ROOT",
"leafs": [
{
"CN": "CSF0",
"description": "CSF End-Entity certificate",
"useCase": "HABCA",
"keyType": "RSA4096",
"certificateType": "ENDENTITY",
"profileID": "$ENDPROFILEID"
},
{
"CN": "IMG0",
"description": "IMG signing certificate",
"useCase": "HABCA",
"keyType": "RSA4096",
"certificateType": "ENDENTITY",
"profileID": "$ENDPROFILEID"
}
]
},
{
"CN": "SRK1",
"description": "CA used for i.MX6 HAB",
"useCase": "HABCA",
"profileID": "$ROOTPROFILEID",
"keyType": "RSA4096",
"certificateType": "ROOT",
"leafs": [
{
"CN": "CSF1",
"description": "CSF End-Entity certificate",
"useCase": "HABCA",
"keyType": "RSA4096",
"certificateType": "ENDENTITY",
"profileID": "$ENDPROFILEID"
},
{
"CN": "IMG1",
"description": "IMG signing certificate",
"useCase": "HABCA",
"keyType": "RSA4096",
"certificateType": "ENDENTITY",
"profileID": "$ENDPROFILEID"
}
]
},
{
"CN": "SRK2",
"description": "CA used for i.MX6 HAB",
"useCase": "HABCA",
"profileID": "$ROOTPROFILEID",
"keyType": "RSA4096",
"certificateType": "ROOT",
"leafs": [
{
"CN": "CSF2",
"description": "CSF End-Entity certificate",
"useCase": "HABCA",
"keyType": "RSA4096",
"certificateType": "ENDENTITY",
"profileID": "$ENDPROFILEID"
},
{
"CN": "IMG2",
"description": "IMG signing certificate",
"useCase": "HABCA",
"keyType": "RSA4096",
"certificateType": "ENDENTITY",
"profileID": "$ENDPROFILEID"
}
]
},
{
"CN": "SRK3",
"description": "CA used for i.MX6 HAB",
"useCase": "HABCA",
"profileID": "$ROOTPROFILEID",
"keyType": "RSA4096",
"certificateType": "ROOT",
"leafs": [
{
"CN": "CSF3",
"description": "CSF End-Entity certificate",
"useCase": "HABCA",
"keyType": "RSA4096",
"certificateType": "ENDENTITY",
"profileID": "$ENDPROFILEID"
},
{
"CN": "IMG3",
"description": "IMG signing certificate",
"useCase": "HABCA",
"keyType": "RSA4096",
"certificateType": "ENDENTITY",
"profileID": "$ENDPROFILEID"
}
]
}
],
"rndKeys": [],
"productOperations": [
{
"name": "HAB CST signing",
"description": "HABCST signing",
"operationType": "SignHAB",
"approvalRule": {
"name": "Test rule",
"description": "Rule used for $PRODUCTNAME",
"allowedGroups": [
"$WRITERGROUP"
],
"approvalGroups": [
"$APPROVERGROUP"
],
"blanketGroups": []
}
},
{
"name": "U-Boot signing",
"description": "U-Boot signing operation",
"operationType": "SignUBoot",
"token": {
"name": "U-Boot",
"description": "HSM token for FIT image U-Boot signing.",
"keyType": "RSA2048"
},
"approvalRule": {
"name": "Test rule",
"description": "Rule used for testing for $PRODUCTNAME",
"allowedGroups": [
"$WRITERGROUP"
],
"approvalGroups": [
"$APPROVERGROUP"
],
"blanketGroups": []
}
},
{
"name": "Kernel signing",
"description": "FIT image kernel signing.",
"operationType": "SignKernel",
"token": {
"name": "Kernel",
"description": "HSM token for FIT image kernel signing.",
"keyType": "RSA2048"
},
"approvalRule": {
"name": "Test rule",
"description": "Rule used for testing for $PRODUCTNAME",
"allowedGroups": [
"$WRITERGROUP"
],
"approvalGroups": [
"$APPROVERGROUP"
],
"blanketGroups": []
}
}
]
}
i.MX8M based products¶
Products based on i.MX8M that require the i.MX8M specific fusemap, need to add the following into the product definition
{
"productConfigItems": [
{
"name": "FusemapType",
"value": "IMX8vS"
}
]
}
If the config item is not present, the backend will default to the i.MX6 fusemap creation.
i.MX8QXP / i.MX9 based product¶
The product consists of the AHAB hierarchy and one product operation to sign the boot container.
Create a PKI profile before product creation. Check a chapter Examples of profiles from the PKI for example (A)HAB templates. ProfileIDs must be replaced with the profile IDs defined in the system as described in the PKI chapter.
- Configuration item named FusemapType with value IMXAHAB
- SignHAB operation which uses CST tool. Uses SRK0->SGK0.
This product generates eight 4096-bit RSA key pairs in the CloudHSM.
{
"name": "$PRODUCTNAME",
"description": "TEST Product for i.MX9 based product",
"productType": "Production",
"enabled": true,
"caInfo": [
{
"CN": "SRK0",
"description": "CA used for i.MX9 AHAB",
"useCase": "HABCA",
"profileID": "$ROOTPROFILEID",
"keyType": "RSA4096",
"certificateType": "ROOT",
"leafs": [
{
"CN": "SGK0",
"description": "SGK End-Entity certificate for $PRODUCTNAME",
"useCase": "HABCA",
"keyType": "RSA4096",
"certificateType": "ENDENTITY",
"profileID": "$ENDPROFILEID"
}
]
},
{
"CN": "SRK1",
"description": "CA used for i.MX9 AHAB",
"useCase": "HABCA",
"profileID": "$ROOTPROFILEID",
"keyType": "RSA4096",
"certificateType": "ROOT",
"leafs": [
{
"CN": "SGK1",
"description": "SGK End-Entity certificate for $PRODUCTNAME",
"useCase": "HABCA",
"keyType": "RSA4096",
"certificateType": "ENDENTITY",
"profileID": "$ENDPROFILEID"
}
]
},
{
"CN": "SRK2",
"description": "CA used for i.MX9 AHAB",
"useCase": "HABCA",
"profileID": "$ROOTPROFILEID",
"keyType": "RSA4096",
"certificateType": "ROOT",
"leafs": [
{
"CN": "SGK2",
"description": "SGK End-Entity certificate for $PRODUCTNAME",
"useCase": "HABCA",
"keyType": "RSA4096",
"certificateType": "ENDENTITY",
"profileID": "$ENDPROFILEID"
}
]
},
{
"CN": "SRK3",
"description": "CA used for i.MX9 AHAB",
"useCase": "HABCA",
"profileID": "$ROOTPROFILEID",
"keyType": "RSA4096",
"certificateType": "ROOT",
"leafs": [
{
"CN": "SGK2",
"description": "SGK End-Entity certificate for $PRODUCTNAME",
"useCase": "HABCA",
"keyType": "RSA4096",
"certificateType": "ENDENTITY",
"profileID": "$ENDPROFILEID"
}
]
}
],
"rndKeys": [],
"productConfigItems": [
{
"name": "FusemapType",
"value": "IMXAHAB"
}
],
"productOperations": [
{
"name": "HAB CST signing",
"description": "HABCST signing",
"operationType": "SignHAB",
"approvalRule": {
"name": "Test rule",
"description": "Rule used for $PRODUCTNAME",
"allowedGroups": [
"$WRITERGROUP"
],
"approvalGroups": [
"$APPROVERGROUP"
],
"blanketGroups": []
}
}
]
}
OCI Signing¶
In order to support OCI signing the product needs to have a configuration item which describes the Registry URL used. E.g.,
{
"productConfigItems": [
{
"name": "RegistryURL",
"value": "33636498317.dkr.ecr.eu-west-1.amazonaws.com"
}
]
}
If the config item is not present, the OCI signing will fail.
Windows Signing¶
To support Windows signing, a Windows signing-enabled product must be created. Create a PKI profile before product creation. Check a chapter Windows signing template from the PKI for examples.
Here is example template of the required product. Replace variables with your own values. This product generates one 2048-bit RSA key pair in the CloudHSM.
{
"name": "$PRODUCTNAME",
"description": "Windows endentity signing for year 2025",
"productType": "Production",
"enabled": true,
"caInfo": [
{
"CN": "$PRODUCTNAME",
"description": "End-Entity certificate for Windows codesigning",
"externalRoot": true,
"useCase": "WinSigning",
"keyType": "RSA2048",
"certificateType": "ENDENTITY",
"profileID": "$WINDOWNSCODESIGNINGPROFILEID"
}
],
"rndKeys": [],
"productOperations": [
{
"name": "Windows signing",
"description": "Sign Windows",
"operationType": "SignWindowsBinary",
"approvalRule": {
"name": "Windows Signing Approval",
"description": "Rule used for approving for $PRODUCTNAME",
"allowedGroups": [
"$WRITERGROUP_FOR_WINDOWSSIGNING"
],
"approvalGroups": [
"$APPROVERGROUP_FOR_WINDOWSSIGNING"
],
"blanketGroups": []
}
}
]
}
RAUC Signing¶
RAUC (Robust Auto-Update Controller) signing ensures secure software updates by utilizing a Public Key Infrastructure (PKI) to create and manage cryptographic keys and certificates. This section explains how to configure a RAUC signing-enabled product, including the creation of a Certificate Authority (CA) and the generation of ephemeral code-signing certificates for secure bundle signing.
Prerequisites¶
Before setting up a RAUC signing-enabled product, you must create PKI profiles. These profiles define the cryptographic parameters and policies for key and certificate generation. For detailed examples, refer to the RAUC Signing Template Examples in the PKI documentation.
Creating a RAUC Signing-Enabled Product¶
To enable RAUC signing, you need to configure a product that generates a Certificate Authority (CA) within a Hardware Security Module (HSM). The CA issues short-lived (ephemeral) code-signing certificates for each RAUC bundle signing operation. Below is an overview of the process and a template for the product configuration.
Product Configuration Template¶
Below is an example template for a RAUC signing-enabled product. Replace the placeholder variables (e.g., $SUBPROFILEID) with your specific values.
{
"name": "$PRODUCTNAME",
"description": "Product for testing RAUC bundle One Time Signing",
"productType": "Production",
"enabled": true,
"caInfo": [
{
"CN": "CA for One Time Signing certs for $PRODUCTNAME",
"description": "One Time Signing RAUC code signing certs",
"useCase": "RaucCodeSigning",
"keyType": "RSA2048",
"certificateType": "SUBCA",
"profileID": "$SUBPROFILEID"
}
],
"productConfigItems": [
],
"rndKeys": [],
"productOperations": [
{
"name": "RAUC code signing cert and key",
"description": "RAUC code signing With end entity cert and key",
"operationType": "RaucBundleSigningWithOneTimeKey",
"profileID": "$ENDSIGPROFILEID",
"token": {
"name": "Token for One Time Signing certificates",
"description": "One Time Signing key for issuing signing certificates",
"keyType": "RSA2048"
},
"approvalRule": {
"name": "Test rule2",
"description": "Rule used for testing for $PRODUCTNAME",
"allowedGroups": [
"$WRITERGROUP"
],
"approvalGroups": [
"$APPROVERGROUP"
],
"blanketGroups": [
]
}
}
]
}
How It Works¶
-
CA Key Generation:
- The product creates a 2048-bit RSA key pair for the Certificate Authority, stored securely in the CloudHSM.
- This CA key pair is used to issue ephemeral signing certificates for RAUC bundles.
-
Ephemeral Key and Certificate Creation:
- For each RAUC bundle signing operation, a new 2048-bit RSA key (ephemeral key) is generated within the HSM.
- The CA issues a signing certificate for the ephemeral key. The certificate's Common Name (CN) is either:
- A randomly generated UUID for uniqueness, or
- A static CN specified in the
CommonNamefield of the template.
- The ephemeral key is not stored persistently in the HSM. Instead, it is protected by a master key stored in the HSM and discarded after use.
-
Security Considerations:
- All cryptographic operations (key generation, certificate issuance, and signing) occur within the security boundary of the HSM.
- The token and profile information specified in the configuration ensure the correct key type and certificate profile are used during operations.
Best Practices¶
- Secure Token and Profile Configuration: Ensure that the HSM token and profile are correctly configured to match your security requirements.
- Validate CN Usage: Decide whether to use a static CN or a UUID based on your application's needs. UUIDs are recommended for uniqueness and traceability.
- Regularly Review PKI Profiles: Periodically check the PKI profiles to ensure they align with your organization's security policies and RAUC requirements.
Next Steps¶
- Create and configure the necessary PKI profiles as described in the RAUC Signing Template Examples.
- Use the provided template to set up your RAUC signing-enabled product, replacing placeholders with your values.
Device Certificate issuance¶
To support Device certificates, a Device CA enabled product must be created. Create a PKI profiles before product creation. Check a chapter Device CA templates from the PKI for examples.
Here is example template of the required product. Replace variables with your own values.
{
"name": "$PRODUCTNAME",
"description": "Device certificate for Initial Device certificates",
"productType": "Production",
"enabled": true,
"caInfo": [
{
"CN": "$PRODUCTNAME",
"description": "Device Identity CA for $PRODUCTNAME",
"externalRoot": false,
"useCase": "DeviceCA",
"keyType": "ECDSAP256",
"certificateType": "ROOT",
"crlIssueInterval": "12h",
"crlExpiry": "24h",
"crlDistributionPoints": [
"http://crl.company.com/e37f045c.crl",
"http://crl.company.com/e435345.crl"
],
"policyIdentifiers": [
],
"profileID": "$ROOTPROFILEID"
}
],
"rndKeys": [],
"productOperations": [
{
"name": "Issue device certificates",
"description": "Device certificates",
"operationType": "IssueDeviceCertificate",
"profileID": "$ENDPROFILEID",
"approvalRule": {
"name": "This is rule",
"description": "desc",
"allowedGroups": [
"$LAAVAT_WRITERGROUP"
],
"approvalGroups": [
],
"blanketGroups": []
}
}
]
}
Digest signing with detached signature¶
To support Digest signing with detached signature, a Digest signing with detached signature-enabled product must be created. Create a PKI profiles before product creation. Check a chapter Digest signing with detached signature template from the PKI for examples.
Here is example template of the required product. Replace variables with your own values. This product generates one 2048-bit RSA key pair in the CloudHSM.
{
"name": "$PRODUCTNAME",
"description": "Product for Digest signing with detached signature based product",
"productType": "RnD",
"enabled": true,
"caInfo": [
{
"CN": "Externally issued End-Entity certificate",
"description": "End-Entity certificate for signing",
"externalRoot": true,
"useCase": "CodeSigning",
"keyType": "RSA2048",
"certificateType": "ENDENTITY",
"profileID": "$ENDSIGPROFILEID"
}
],
"rndKeys": [],
"productOperations": [
{
"name": "Generate detached signature with CodeSigning key",
"description": "Generate detached signature with CodeSigning key",
"operationType": "DetachedSignature",
"approvalRule": {
"name": "Test rule",
"description": "Rule used for testing",
"allowedGroups": [
"$WRITERGROUP"
],
"approvalGroups": [
"$APPROVERGROUP"
],
"blanketGroups": []
}
}
]
}
Example usage with reference client package: Creating product¶
Modify the product template file to include the ROOT and End-Entity profile ID:s (Acquired through profile --getall)
export PRODUCTNAME=TESTPROD
export ROOTPROFILEID=76de3349-3707-4744-b7d0-93ae7ea349c0
export ENDPROFILEID=60b3ff9e-27f9-403c-b125-e018080a6366
envsubst < product.template > product.test
You should also take care to fill in the group information for the different product operations in the template.
Request product creation:
(venv) $ ./signing-tool.py -c -t $TOKEN -a \
https://app.laavat.io/<CustomerName>/api/v1 product \
add -T k-imx-product.test
Product:
{
<Redacted for readability>
}
Is product ok(Y/N): y
{
"ca_info": [],
"description": "Product for new i.MX6 based productTEST",
"enabled": null,
"external_request_id": null,
"id": "b508d600-977a-46f4-9070-5cf56646bae1",
"name": "TESTPROD",
"product_config_items": null,
"product_operations": [],
"product_type": null,
"rnd_keys": [],
"state": 2
}
Product Add request sent. Request ID: b508d600-977a-46f4-9070-5cf56646bae1 state: ApprovalRequired
Approve the product:
(venv) $ ./signing-tool.py -c -t $APPTOKEN -a \
https://app.laavat.io/<CustomerName>/api/v1 product approve -I b508d600-977a-46f4-9070-5cf56646bae1
Approve product
product ID: b508d600-977a-46f4-9070-5cf56646bae1
{
<Redacted for readability>
}
Do you want approve this (Y/N): y
You can check the status of the product with (state 8 is in progress and 16 is completed):
(venv) $ ./signing-tool.py -c -t $APPTOKEN -a https://app.laavat.io/<CustomerName>/api/v1 \
product get -I b508d600-977a-46f4-9070-5cf56646bae1
Get product secrets¶
You can get product secrets like KEK IV, SRKTable and SRKHash with the following:
(venv) $ ./signing-tool.py -c -t $TOKEN -a https://app.laavat.io/<CustomerName>/api/v1 secrets \
get -P b508d600-977a-46f4-9070-5cf56646bae1 \
-C client.private -O testings.out
KEKIV written to: testings.outKEKIV
SRKTABLE written to: testings.outSRKTABLE
SRKHASH written to: testings.outSRKHASH
Full secret payload written to: testings.out
(venv) $
Please note that the secrets are only decrypted if you provide the client private key with the -C flag. Otherwise the encrypted JWE payload will be dumped to the output file. You may provide a password for the key if it is password protected with --keypass