Keeper “One-Time Share” provides time-limited secure sharing of a record to anyone without having to create a Keeper account. One-Time Share is the most secure way to send confidential information to an external person or contractor without exposing information over email, text message or messaging.
One-Time Shares are secure by design, utilizing Keeper’s Zero-Knowledge encryption. The record data is decrypted locally on the recipient’s device using 256-bit AES and all requests to the server are signed with elliptic-curve cryptography (ECDSA).
Use Cases
- Share access credentials with a contractor
- Share an encrypted file with a co-worker
- Provide secure documentation or instructions
Delivery of One-Time Shares
- One-Time Share links can be sent to recipients through any trusted channel, such as:
- Direct QR Code Scan
- Airdrop
- SMS
- Enterprise messaging platforms
- Any other out-of-band channel.
The applications and uses for this are virtually endless.
Any time you have a need to securely deliver data to a non-Keeper user, One-Time Shares are the perfect choice.
Security and Encryption Model
The encryption model implemented for one-time sharing uses the same technology as Keeper Secrets Manager, a zero-knowledge and zero-trust platform for protecting cloud infrastructure.
The security model and method of encryption is detailed below:
(1) In the vault, the sharer generates a one-time access token by clicking on “One-Time Share” in the record options screen. The 256-bit AES Record Key for the record being shared is encrypted with the one-time access token, and this encrypted value is stored in the Keeper Cloud.
(2) The sharer sends the One-Time Access Token to a recipient via a simple URL or QR code through their preferred channel. The URL portion that contains the access token is held within the “fragment identifier” section of the URL which is never sent over the network to Keeper’s servers. Therefore, zero-knowledge is retained and Keeper has no ability to access or decrypt the information.
(3) The recipient opens the URL on their device browser, and a single-page Vault application is loaded on the device. The One-Time Access Token is handed off directly to the local vault application (not sent to the server).
(4) Upon loading the URL, the recipient’s device generates a client-side public/private Elliptic Curve key pair, and the private key is stored locally on the Client Device in the browser’s CryptoKey storage.
(5) Upon first use, the SDK library authenticates using the hash of the One Time Access Token and upon successful authentication, the server responds with the encrypted record ciphertext plus the Encrypted Record Key.
(6) The Client decrypts the Record Key with the One Time Access Token, and the record contents are decrypted using the Record Key. The Record Key is then stored locally on the client device in the browser’s CryptoKey storage or other designated storage location.
(7) On the server, the encrypted record key for that given device is deleted so that the One Time Access Token cannot be used again. After that, the client’s requests must be signed with the Client Private Key.
(8) Subsequent calls on the same device to the server are sent with an identifier which uniquely defines the device (hash of the one-time access token) and a request body that is signed with the Client Private Key. The server checks the ECDSA signature of the request for the given device identifier using the Client Public Key of the device. The Keeper Cloud processes the request for the record, and the server returns encrypted record ciphertext to the Client upon successful authentication.
(9) In addition to the record-level encryption, the Client Device creates a randomly generated AES-256 bit Transmission Key which is encrypted with the public key of the Keeper cloud API. The Client Device decrypts the response from the server with the Transmission Key and then decrypts the ciphertext response payload with the Record Key, which decrypts the contents of the record.
