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:

  1. Create an encrypted container

  2. Grant cryptographically enforced access to an external user

  3. Retrieve and decrypt the container as the authorized user

  4. Revoke external access

  5. 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.