Zelta/Documentation
GitHub

Key Management

Best practices for managing your firmware signing keys.

Key Storage

Private Key

The private key is the most sensitive part of your security infrastructure.

DO:

  • Store in a hardware security module (HSM) for production
  • Use encrypted storage with strong passphrase
  • Limit access to authorized personnel only
  • Keep offline backups in secure locations
  • Use separate keys for development and production

DON'T:

  • Store in version control
  • Share via email or chat
  • Keep on developer machines long-term
  • Reuse keys across organizations
  • Store alongside public key

Public Key

The public key can be freely distributed.

Best Practices:

  • Embed in firmware at compile time
  • Store in organization settings
  • Include key fingerprint in release notes
  • Document key rotation schedule

Key Rotation

Rotate signing keys periodically to limit exposure from potential compromise.

Rotation Process

  1. Generate new keypair in the Dashboard
  2. Create transition firmware containing both old and new public keys
  3. Sign transition firmware with the old key
  4. Deploy to all devices via normal OTA
  5. Verify all devices updated via Dashboard
  6. Switch to new key for signing new firmware
  7. Archive old key securely (for verifying old signatures)
  8. Update documentation with new key fingerprint

Rotation Schedule

| Environment | Recommended Frequency | |-------------|----------------------| | Development | Every release | | Staging | Quarterly | | Production | Annually |

Key Fingerprints

Zelta uses SHA-256 fingerprints to identify keys:

Key Fingerprint: A1B2C3D4E5F67890

The fingerprint is:

  • First 16 hex characters of SHA-256 hash of public key PEM
  • Stored with each firmware to track which key signed it
  • Displayed in Dashboard for verification

Checking Fingerprints

In the Dashboard:

  1. Go to Firmware page
  2. Click on any firmware version
  3. View Key Fingerprint in signature details

Compromise Response

If you suspect your private key has been compromised:

Immediate Actions

  1. Stop signing with the compromised key
  2. Generate new keypair immediately
  3. Notify your security team
  4. Review recent firmware uploads for unauthorized changes

Recovery Process

  1. Push emergency update with new public key (signed with old key)
  2. Monitor device update status in Dashboard
  3. Block API keys that may have been exposed
  4. Audit update logs for suspicious activity
  5. Document incident for compliance

Prevention

  • Use HSM for production signing
  • Enable MFA for Dashboard access
  • Monitor signing activity with alerts
  • Regular security audits

Multi-Key Architecture

For advanced security, consider multiple keys:

| Key Type | Purpose | |----------|---------| | Development | Testing and internal builds | | Staging | Pre-production validation | | Production | Customer deployments | | Emergency | Rollback and recovery |

Devices can be configured to accept multiple public keys, enabling:

  • Gradual key rotation
  • Emergency recovery
  • Multi-party signing (future feature)

Compliance Considerations

Audit Trail

Zelta maintains a complete audit trail:

  • Every firmware upload is logged
  • Key fingerprint stored with each firmware
  • User who performed upload recorded
  • Timestamp and IP address captured

Export Controls

Firmware with encryption may be subject to export controls:

  • ECDSA P-256 is generally not export-controlled
  • Check local regulations for your jurisdiction
  • Document key management procedures

Next Steps