Identity and Key Management
Overview
This guide describes how Locktera manages identities and encryption keys to enforce cryptographic access control for containers.
Locktera separates identity, authorization, and encryption into independent cryptographic layers. Containers remain encrypted at all times, and decryption is permitted only when an authorized identity successfully requests access.
Keys are never shared directly between users. Instead, Locktera securely manages encryption and key authorization so that access can be granted, revoked, or restricted without re-encrypting container contents.
This ensures encryption keys remain protected, access remains enforceable, and container security persists regardless of storage location, infrastructure, or system compromise.
Core Principles
Locktera key management is based on four principles:
• Identity-bound authorization
• Container-level encryption
• Independent access enforcement
• Revocable cryptographic access
These principles ensure secure and scalable key management across distributed environments.
Identity Model
Every access request is associated with a cryptographic identity.
Identities may represent:
• Users
• Applications
• Services
• Devices
• AI systems
• Deployment environments
Each identity is authenticated using:
• API keys
• Identity tokens
• Certificates
• Secure runtime identity
Access is granted to identities, not infrastructure.
Container Encryption Model
Each container is encrypted using a unique container encryption key.
This ensures:
• Containers are cryptographically isolated
• Keys are not shared between containers
• Compromise of one container does not expose others
• Encryption remains independent of storage provider
Container encryption occurs before storage or transfer.
Storage systems never receive plaintext or encryption keys.
Access Authorization Model
Access to container encryption keys is controlled through container access policies.
When an identity attempts to decrypt a container:
-
Identity is authenticated
-
Access policy is evaluated
-
Decryption key is authorized or denied
-
Decryption occurs only if authorized
If authorization fails, decryption is cryptographically denied.
Encryption keys are never exposed to unauthorized identities.
Key Lifecycle
Locktera manages encryption keys throughout their lifecycle.
Key Creation
When a container is created:
• A unique encryption key is generated
• Key is bound cryptographically to the container
• Container contents are encrypted
Example:
curl -X POST $BASE_URL/users/USER_ID/containers/encode \
-H "Authorization: Bearer YOUR_API_KEY" \
-F "file=@sensitive_document.pdf"Response:
{
"org_id": "YOUR_USER_ID",
"container": {
"uuid": "123e4567-e89b-12d3-a456-426614174000"
}
}The encryption key is created automatically and managed securely.
Key Authorization
Access to container keys is granted by authorizing identities.
Example:
curl -X PATCH $BASE_URL/users/USER_ID/containers/CONTAINER_ID/drm \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"recipients": [
"authorized.user@company.com"
]
}'This authorizes the identity to decrypt the container.
The container encryption key remains protected.
Key Usage
Authorized identities may decrypt the container.
Example:
curl -X GET $BASE_URL/users/USER_ID/containers/CONTAINER_ID/decode \
-H "Authorization: Bearer AUTHORIZED_API_KEY"Response:
{
"org_id": "YOUR_USER_ID",
"container": {
"uuid": "123e4567-e89b-12d3-a456-426614174000",
"files": [
{
"name": "sensitive_document.pdf"
}
]
}
}The encryption key is used internally and never exposed.
Key Revocation
Access to encryption keys may be revoked instantly.
Example:
curl -X PUT $BASE_URL/users/USER_ID/containers/CONTAINER_ID/block \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{"reason": "Revoked"}'This prevents further decryption.
Previously authorized identities can no longer decrypt the container.
No re-encryption is required.
Manifest-Based Access Control
Access policies may also be defined at container creation using manifest.json.
Example:
manifest.json
{
"container": {
"recipients": [
"authorized.user@company.com"
],
"downloadable": true,
"drm": {
"dynamic": true
}
}
}This binds key authorization directly to the container.
Identity Enforcement Architecture
Container decryption follows this sequence:
Identity Request
│
▼
Identity Authentication
│
▼
Access Policy Evaluation
│
▼
Key Authorization
│
▼
Container Decryption (if authorized)
Unauthorized identities cannot access keys.
Key Isolation
Locktera ensures strict key isolation.
This ensures:
• Each container uses a unique encryption key
• Keys are not reused across containers
• Keys are not shared between tenants
• Key compromise cannot propagate
Each container is cryptographically independent.
Infrastructure Independence
Key security does not depend on infrastructure security.
Keys remain protected even if:
• Storage is compromised
• Containers are copied
• Infrastructure is breached
• Systems are untrusted
Keys remain protected by cryptographic authorization.
Audit Logging of Key Access
All key usage events are audit logged.
Example:
curl -X GET $BASE_URL/users/USER_ID/containers/CONTAINER_ID/events \
-H "Authorization: Bearer YOUR_API_KEY"Audit logs include:
• Identity requesting access
• Timestamp
• Authorization result
• Operation performed
This enables compliance and forensic analysis.
Deployment Models
Key enforcement operates consistently across all deployment models:
• Cloud environments
• On-premise deployments
• Kubernetes clusters
• Edge systems
• Device deployments
• Hybrid infrastructure
Key security is independent of deployment environment.
Security Guarantees
Locktera key management ensures:
• Encryption keys are never exposed to unauthorized identities
• Access is enforced cryptographically
• Key authorization is identity-based
• Keys remain protected regardless of infrastructure
• Access may be revoked instantly
• Containers remain encrypted at all times
• Key usage is audit logged
• Infrastructure compromise cannot expose keys
Use Cases
This architecture is used for:
• Secure enterprise data protection
• Multi-tenant SaaS security
• Secure AI and model protection
• Secure firmware and OTA updates
• Secure backup and archive protection
• Secure data sovereignty enforcement
Summary
Locktera enforces cryptographic identity-based key management to secure encrypted containers.
Each container is encrypted with a unique key, and access is granted only to explicitly authorized identities. Keys remain protected, access is revocable instantly, and enforcement persists regardless of infrastructure, storage, or distribution.
This enables secure, scalable, and infrastructure-independent data protection across cloud, enterprise, and device environments.
