Secure System-to-System File Transfer

Overview

This guide shows how to securely transfer files between applications and systems using encrypted containers with cryptographically enforced access control.

Traditional file transfer mechanisms such as SFTP, shared storage, and presigned URLs rely on storage-layer permissions or temporary credentials. Once files are transferred, access control can no longer be enforced reliably, and access may persist indefinitely if copies are made.

Locktera secures file transfers by encrypting files into immutable containers and enforcing access policies cryptographically. Access remains cryptographically enforceable regardless of where the container is stored, transferred, or copied, and cannot be bypassed by storage or transport systems.

This ensures that files remain protected throughout their entire lifecycle, including during transfer, after delivery, and regardless of where the container is stored or copied.

What You Will Build

In this guide, you will:

  1. Encrypt a file into an immutable container for secure transfer

  2. Transfer the encrypted container to another application or system

  3. Grant the recipient cryptographic permission to access the container

  4. Retrieve and decrypt the container as the authorized recipient

  5. Retrieve audit records to verify file transfer and access activity

Key Concepts

Secure Transfer Containers

Files are securely transferred by encrypting them into a container before transmission. The container becomes a secure cryptographic object that enforces access control and audit logging.

Secure transfer containers:

  • Encrypt files before transfer

  • Prevent unauthorized decryption

  • Remain secure across system boundaries

  • Enforce access policies independently of storage

  • Generate audit records for all access attempts

Container contents remain immutable.

Persistent Access Control

Access policies remain enforced after transfer.

This ensures:

  • Only authorized recipients can decrypt the container

  • Access can be revoked after transfer

  • Access can be time-limited

  • Access attempts are audit logged

Access enforcement is independent of storage systems, transfer mechanisms, and infrastructure-level permissions.

Storage and Transport Independence

Encrypted containers may be transferred using any transport mechanism, including:

  • HTTP or HTTPS

  • Cloud storage platforms

  • Messaging systems

  • Email attachments

  • File transfer systems

Security remains enforced regardless of transport method.

Common Use Cases

This workflow is commonly used for:

  • Secure file transfer between applications

  • Secure file transfer between microservices

  • Secure partner and vendor file exchange

  • Secure transfer of sensitive enterprise data

  • Replacing SFTP or presigned URL workflows

  • Secure software update and upgrade distribution

Architecture Flow

Application A

     │ Encrypt file into container

Encrypted Container (.tera)

     │ Transfer via network, storage, or messaging system

Application B

     │ Decrypt container (if authorized)

File securely accessed

Prerequisites

  • Locktera API key (sender)

  • Locktera API key (recipient)

  • File to transfer

Base URL:

https://share.locktera.com/api/v1

Authentication header:

Authorization: Bearer YOUR_API_KEY

Step 1 — Encrypt File for Transfer

The sending application encrypts the file into a container.

Request

manifest.json

{
  "container": {
    "recipients": ["authorized.recipient@company.com"],
    "downloadable": true,
    "drm": {
      "dynamic": true
    }
  }
}

curl -X POST $BASE_URL/users/YOUR_USER_ID/containers/encode \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -F "manifest.json=@manifest.json;type=application/json" \
  -F "file=@sensitive_document.pdf" \
  -F "name=Secure Transfer Container"

Response

{
  "org_id": "YOUR_USER_ID",
  "container": {
    "uuid": "CONTAINER_ID",
    "name": "Secure Transfer Container",
    "recipients": [
      "authorized.recipient@company.com"
    ],
    "downloadable": true,
    "drm": {
      "dynamic": true
    }
  }
}

The file is now encrypted and secured in a container.

Step 2 — Transfer Container to Recipient System

The encrypted container may be transferred using any mechanism, such as:

  • Cloud storage

  • API transfer

  • Message queue

  • File transfer system

The container remains encrypted during transfer and cannot be decrypted without cryptographic authorization.

Step 3 — Grant Recipient Access

Grant the recipient permission to decrypt the container.

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"
    ],
    "drm": {
      "time": {
        "start": "2026-02-21T00:00:00Z",
        "end": "2026-03-21T00:00:00Z"
      }
    }
  }'

Response

{
  "recipients": [
    "authorized.recipient@company.com"
  ],
  "drm": {
    "time": {
      "start": "2026-02-21T00:00:00Z",
      "end": "2026-03-21T00:00:00Z"
    }
  }
}

The recipient is now authorized to decrypt the container.

Step 4 — Recipient Retrieves and Decrypts Container

The receiving application retrieves and decrypts the container.

Request

curl -X GET $BASE_URL/users/{user_id}/containers/{container_id}/decode \
  -H "Authorization: Bearer RECIPIENT_API_KEY"

Response

{
  "files": [
    {
      "name": "sensitive_document.pdf"
    }
  ]
}

The recipient application may now securely process the file.

Step 5 — Audit Transfer and Access Activity

Retrieve audit records for the container.

Request

curl -X GET $BASE_URL/users/{user_id}/containers/{container_id}/audit \
  -H "Authorization: Bearer YOUR_API_KEY"

Audit records provide verifiable visibility into who accessed the container, when access occurred, and which system performed the operation.

Security Properties

This workflow ensures:

• Files are encrypted before transfer
• Container authenticity and integrity are cryptographically verified
• Access remains enforceable after transfer
• Unauthorized systems cannot decrypt files
• Access may be revoked at any time
• Containers remain immutable and tamper-resistant
• No reliance on storage-layer permissions
• All access events are audit logged
• Access enforcement persists even if containers are copied, transferred, or stored in untrusted environments
• Storage or transport system compromise alone cannot expose protected files
• All access events are audit logged
• Access enforcement persists even if containers are copied, transferred, or stored in untrusted environments

Comparison to Traditional File Transfer Methods

Traditional file transfer mechanisms rely on infrastructure-level access control:

• SFTP relies on server access permissions
• Presigned URLs rely on temporary credentials
• Shared storage relies on platform access control

Locktera enforces access cryptographically at the container level. Access remains enforceable even if the container is copied, transferred, or stored in untrusted environments.

Summary

Locktera enables secure file transfer between applications by encrypting files into immutable containers with persistent cryptographic access control. Files remain protected during transfer and after delivery, ensuring that only authorized recipients can decrypt and access sensitive data, regardless of where the container is stored or copied.