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:
-
Encrypt a file into an immutable container for secure transfer
-
Transfer the encrypted container to another application or system
-
Grant the recipient cryptographic permission to access the container
-
Retrieve and decrypt the container as the authorized recipient
-
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.
