Share Files Securely with Cryptographically Enforced Access Control
Overview
This guide shows how to securely share an encrypted container with external users or systems while maintaining cryptographic control over access.
Locktera allows containers to be shared without exposing plaintext or relying on storage-layer permissions. Revocation can be applied globally to all external recipients or selectively to individual recipients using container access policies. Revocation immediately prevents future authorized decryption of the container, regardless of where it is stored or copied.
This ensures that access control remains cryptographically enforceable even after the container has been distributed.
What You Will Build
In this guide, you will:
-
Create an encrypted container
-
Grant cryptographically enforced access to an external user
-
Retrieve and decrypt the container as the authorized user
-
Revoke external access
-
Confirm that decryption is no longer permitted
Key Concepts
Access Control Enforcement
Access to containers is governed by cryptographically enforced container policies.
Access permissions can be:
-
Granted to specific users or systems
-
Revoked at any time
-
Limited by time or policy
Container contents remain immutable. Access control policies are evaluated at the time of decryption, ensuring revoked recipients cannot decrypt previously shared containers.
Revocation
Revocation immediately prevents future authorized decryption of the container.
There are two types of revocation:
1. Full Container Revocation
Full revocation removes decryption permission for all external recipients, leaving access only to the container owner.
This is performed using the container block endpoint:
PUT /users/{user_id}/containers/{container_id}/block
Full revocation is appropriate when:
-
The container should no longer be shared externally
-
An incident requires immediate external access removal
-
All external permissions must be invalidated at once
2. Selective Recipient Revocation
To revoke access for a specific recipient while preserving access for others, update the container’s recipient list using the DRM endpoint:
PATCH /users/{user_id}/containers/{container_id}/drm
This modifies the container’s access policy without affecting other authorized users.
Revocation does not require:
-
Modifying the container
-
Re-encrypting the container
-
Moving the container
Access enforcement remains independent of storage location.
Architecture Flow
Container Owner
│
│ Grant access
▼
Authorized External User
│
│ Retrieve and decrypt (authorized)
▼
Encrypted Container (.tera)
│
│ Access revoked
▼
Access denied
Prerequisites
-
Locktera API key (owner)
-
Locktera API key (external user)
-
Existing container ID
Base URL:
https://share.locktera.com/api/v1
Authentication header:
Authorization: Bearer YOUR_API_KEY
Step 1 — Create an Encrypted Container
Create a container as shown in the Secure File Upload and Storage guide.
Example container:
container_id: 123e4567-e89b-12d3-a456-426614174000
Step 2 — Grant Access to an External User
Grant access to the container using the DRM (access control) endpoint.
Request
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.recipient@company.com"]
}'
Response
{
"recipients": [
"authorized.recipient@company.com"
]
}
The external user is now authorized to decrypt the container.
Step 3 — Retrieve Container as Authorized User
The external user retrieves the container.
Request
curl -X GET $BASE_URL/users/{user_id}/containers/{container_id}/decode?viewer=authorized.recipient@company.comcom \
-H "Authorization: Bearer YOUR_API_KEY"
Decoding with the API key must be authorized by an API key within the organization that has access to the container, on behalf of a viewer that is specified in the viewer= query parameter. This operation should be performed on a secure server to ensure the viewer is never in possession of the API key.
If both the API key and viewer address are authorized:
-
Container decryption is permitted
-
Access is logged
-
Audit record is generated
Step 4 — Revoke Access
The container owner performs full container revocation, removing access from all external recipients.
Request
curl -X POST $BASE_URL/users/{user_id}/containers/{container_id}/block \
-H "Authorization: Bearer YOUR_API_KEY" \
-d '{
"reason": "Revoked"
}'
Access has now been revoked.
Step 5 — Verify Access Revocation
The external user attempts to retrieve the container again.
Request
curl -X GET $BASE_URL/users/{user_id}/containers/{container_id}/decode?viewer=authorized.recipient@company.comcom \
-H "Authorization: Bearer EXTERNAL_USER_API_KEY"
Response
{
"error": "access_denied",
"message": "You do not have permission to access this container."
}
Result
Access is denied.
Container decryption is not permitted.
Container contents remain protected.
Security Properties
This workflow ensures:
-
Containers can be shared securely without exposing plaintext
-
Access is enforced cryptographically
-
Access can be revoked without modifying the container
-
Access enforcement persists regardless of storage location
-
All access and revocation events are audit logged
-
Full revocation removes access for all external recipients, while DRM policies allow selective recipient removal
Common Integration Patterns
This pattern is commonly used for:
-
Sharing files with external vendors
-
Providing regulators access to records
-
Granting temporary contractor access
-
Secure evidence sharing
-
Secure enterprise data sharing
Summary
Locktera allows encrypted containers to be shared securely while maintaining persistent cryptographic control over access. Access can be granted and revoked at any time without modifying or re-encrypting the container, ensuring that control over sensitive data remains enforceable regardless of where it is stored or distributed.
