PROVISIONAL PATENT APPLICATION
Under 35 U.S.C. § 111(b)
Title of the Invention
SYSTEM AND METHOD FOR MUTUAL-CONSENT CONDITIONAL ACCESS TO AN ENCRYPTED RECORDING OF AN INTERPERSONAL ENCOUNTER, WITH TIME-LOCKED RELEASE, JOINT REDACTION, AND UNILATERAL CRYPTOGRAPHIC DESTRUCTION
Inventor: David Clayman, Boca Raton, Florida, United States
Filing note: This specification is intended to be accompanied by USPTO form SB/16 (Provisional Application for Patent Cover Sheet) and the applicable filing fee. Claims are not required in a provisional application; the claims herein are included as part of the disclosure to support the full scope of a later nonprovisional application.
Statement Regarding Federally Sponsored Research or Development
[0001] Not applicable.
Field of the Invention
[0002] The present disclosure relates generally to cryptographic access control for recorded media, and more particularly to systems and methods in which a recording of an interpersonal encounter between two or more participants is encrypted at capture and rendered accessible only upon the contemporaneous, verified, mutual consent of the participants, subject to a time-lock condition, with provision for jointly authorized redaction by cryptographic erasure and for unilateral, irreversible destruction of the recording by any single participant.
Background
[0003] Interpersonal encounters conducted over video communication platforms, and interpersonal encounters recorded by personal devices generally, may be recorded for later sentimental, evidentiary, or commemorative use. Conventional recording systems place the resulting media file under the control of a single party — typically the meeting host, the platform operator, or the device owner. Such unilateral control is poorly suited to intimate or sensitive encounters, in which each participant has a legitimate and continuing interest in whether, when, and by whom the recording may ever be viewed.
[0004] Known access-control approaches for recorded content, including conventional digital rights management and conventional server-side permission systems, share a common deficiency: a single custodian (the platform, the host, or a rights holder) retains the technical ability to decrypt or disclose the content without the concurrence of all recorded participants. Such systems also generally lack any mechanism by which the recorded participants may jointly and permanently excise portions of the recording, or by which any single participant may permanently and verifiably destroy the recording notwithstanding the objection of the other participant or of the custodian. A need therefore exists for a recording architecture in which access is technically impossible — not merely administratively prohibited — absent the verified mutual consent of the recorded participants, and in which destruction rights are asymmetric to access rights: access requires unanimity, while destruction may be effected unilaterally.
Summary of the Invention
[0005] In one aspect, a system captures a recording of an encounter between a first participant and a second participant, the recording comprising audio, video, or both, each participant providing recorded affirmative consent at the commencement of capture. The recording is encrypted substantially at capture under an ephemeral content key. The content key is divided under a threshold secret-sharing scheme into a plurality of key shares, including at least a first share delivered to and held exclusively in a protected keystore of the first participant's device, a second share delivered to and held exclusively in a protected keystore of the second participant's device, and a third share retained by a policy server subject to a release policy. The assembled content key is then destroyed, such that no single entity — including the operator of the system — possesses sufficient key material to decrypt the recording.
[0006] In another aspect, the release policy of the policy server conditions release of the server-held share upon at least: (a) expiration of a predetermined time-lock interval measured from the time of capture; (b) receipt of fresh, cryptographically signed mutual attestations from both participants, generated within a validity window, affirming each participant's present consent to decryption; and (c) verification of the contemporaneous co-presence and liveness of both participants at the time of the unlock request. Decryption occurs within a session-bound protected environment, and playback may be forensically watermarked with session identifiers.
[0007] In another aspect, during a joint decryption session, the participants may jointly designate one or more segments of the recording for redaction. The system generates a redacted copy omitting the designated segments, encrypts the redacted copy under a new content key that is re-split and re-distributed as above, and thereafter effects cryptographic erasure of the original recording by destroying all shares of the original content key, rendering the original ciphertext permanently unrecoverable.
[0008] In another aspect, either participant may at any time, unilaterally and without the concurrence of the other participant or of the system operator, direct the verified destruction of that participant's own key share, thereby rendering the recording permanently undecryptable by all parties. This asymmetry — unanimous consent required for access, unilateral action sufficient for destruction — is a defining property of the disclosed architecture.
[0009] Further aspects include: capture embodiments for both platform-hosted virtual encounters and co-located in-person encounters recorded by a participant device; client-side encryption embodiments in which plaintext media never transits operator infrastructure; participant-selectable storage modes in which the ciphertext resides exclusively on the participant devices under an additional device-bound storage wrapping, or on operator infrastructure under an additional participant-derived envelope encryption that the operator cannot decrypt, or both, with identical access-control guarantees in every mode; generalization to N participants under a T-of-N threshold in which T includes all recorded participants plus a policy share; hardware-protected embodiments in which shares are sealed in secure enclaves, trusted execution environments, or hardware security modules; and audit-log embodiments in which every consent event, attestation, unlock, redaction, and destruction is recorded in an append-only, tamper-evident log available to both participants.
Brief Description of the Drawings
[0010] FIG. 1 is a block diagram of a system architecture (100) according to an embodiment, showing participant devices (110, 120), a session service and media capture component (130), an encryption engine (140), an encrypted recording store (150) which, as described below, may reside on operator infrastructure, on the participant devices, or both, a policy server (160), and an audit log (170).
[0011] FIG. 2 is a block diagram of key generation and threshold distribution (200) according to an embodiment, showing generation of an ephemeral content key (210), a two-of-three threshold split (220), distribution of shares to a first participant device keystore (230), a second participant device keystore (240), and a policy server (250), and destruction of the assembled key (260).
[0012] FIG. 3 is a flow diagram of a conditional joint unlock ceremony (300) according to an embodiment, showing an unlock request (310), a time-lock check (320), fresh mutual attestation (330), co-presence and liveness verification (340), conditional release of the server share (350), reconstruction of the content key in a protected session (360), and session-bound decryption with watermarked playback (370).
[0013] FIG. 4 is a flow diagram of joint redaction and cryptographic erasure (400) according to an embodiment, showing a joint decryption session (410), joint designation of segments for redaction (420), production of a re-encrypted redacted copy (430), re-splitting of the new key (440), destruction of all shares of the original key (450), resulting unrecoverability of the original ciphertext (460), and the unilateral destruction pathway (470).
Detailed Description
1. Overview and Definitions
[0014] The following description sets forth specific embodiments to provide a thorough understanding of the invention. The invention may be practiced without one or more of the specific details described, and features of different embodiments may be combined. As used herein, an “encounter” includes without limitation a first romantic date, a subsequent date, a conversation, a ceremony (such as an exchange of vows), a mediation, an intimate or private encounter between adult partners, or any other interpersonal interaction the participants elect to record; a “participant” is a natural person recorded during the encounter; “cryptographic erasure” means rendering ciphertext permanently unrecoverable by verified destruction of all key material necessary for its decryption; and a “protected keystore” includes an operating-system keystore, a secure enclave, a trusted execution environment (TEE), a hardware security module (HSM), or functionally equivalent hardware- or software-protected storage. “Media” and “recording” mean audio alone, video alone, audio and video together, or any of the foregoing together with derived artifacts such as a transcript, and nothing herein requires the capture of video; every capture, encryption, key-management, storage, unlock, redaction, and destruction operation described herein applies identically to audio-only recordings.
2. System Architecture (FIG. 1)
[0015] Referring to FIG. 1, system 100 comprises a first participant device 110 and a second participant device 120, each running a client application; a session service 130 that hosts or joins the encounter and captures the media streams; an encryption engine 140 that encrypts captured media substantially at capture; an encrypted recording store 150 that persists only ciphertext; a policy server 160 that holds a policy-controlled key share and evaluates a release policy; and an append-only audit log 170. In a preferred embodiment the session service 130 is a real-time communication service operated by the system (for example, a WebRTC selective forwarding unit or an embeddable video SDK), so that raw media never transits a third-party recording pipeline. In alternative embodiments the session service 130 receives media streams from a third-party conferencing platform through that platform's real-time media interface, subject to the platform's participant-consent mechanisms, or receives media from a camera and microphone of a participant device recording a co-located, in-person encounter.
[0016] At the commencement of capture, each participant provides an affirmative, on-the-record consent to recording, which is captured both as recorded media and as a cryptographically signed consent artifact bound to the participant's enrolled identity key. Capture does not proceed absent both consent artifacts. In embodiments directed to intimate encounters between adult partners, enrollment further comprises verification that each participant is an adult, performed by one or more of: verification against a government-issued identity document, a device- or platform-attested age signal, or a third-party age-assurance service; the verification result, but not the underlying identity document or biometric data, is bound to the participant's identity key as a signed age-assurance artifact, and capture of an encounter designated as intimate does not proceed absent a valid age-assurance artifact for every participant. Each consent artifact, each age-assurance artifact, and every subsequent lifecycle event described herein, is written to audit log 170 in an append-only, hash-chained structure such that neither participant nor the operator can retroactively alter the event history without detection.
3. Encryption at Capture and Segmentation
[0017] Encryption engine 140 encrypts the media stream substantially contemporaneously with capture using an authenticated encryption scheme. In a preferred embodiment, the stream is divided into time-indexed segments (for example, segments of between one and thirty seconds), and each segment i is encrypted under a per-segment key K_i derived from an ephemeral master content key K by a key-derivation function (for example, HKDF with the segment index and a per-recording salt as context). Per-segment keying supports the segment-level redaction described below, because destruction of the key material for a designated segment renders that segment alone unrecoverable. In a preferred embodiment the authenticated cipher is AES-256-GCM or XChaCha20-Poly1305; associated data for each segment binds the segment to the recording identifier, segment index, and participant identity keys, so that segments cannot be reordered, substituted, or transplanted between recordings without detection.
[0018] Plaintext media is held only transiently in volatile memory of the capture path and is never written to durable storage. In server-side capture embodiments, encryption engine 140 operates on the capture server, preferably within a trusted execution environment. In client-side capture embodiments, the encryption engine operates within the client application of each participant device, media is exchanged peer-to-peer or captured locally (as in the in-person embodiment), and plaintext media never transits or resides on operator infrastructure in any form.
[0019] The storage location of the ciphertext is selectable by the joint election of the participants at capture, and is orthogonal to the access-control architecture described herein: in every storage mode, decryption requires reconstruction of the content key from the jointly necessary participant shares together with the policy-governed server share, so that the mutual-consent, time-lock, redaction, and unilateral-destruction guarantees are identical regardless of where the ciphertext resides. In a device-resident storage mode, the ciphertext is stored exclusively on the participant devices, preferably as a replica on each participant device for redundancy against device loss, and each local replica is additionally wrapped under a storage key bound to the respective device's protected keystore, such that the recording is protected by at least two independently held protections (the split content key and the device-bound storage wrapping) and the operator at no time possesses the ciphertext. In an operator-hosted storage mode, the ciphertext is stored in encrypted recording store 150, which may be commodity object storage, protected by at least three independently held protections: (i) the content encryption under the split content key; (ii) an outer envelope encryption of the stored object under a storage envelope key derived jointly from key material of both participant devices and not held by the operator, such that the operator cannot decrypt even the outer envelope of the object it stores; and (iii) sealing of the server share within the hardware security module or trusted execution environment of the policy server. In a hybrid storage mode, replicas are maintained both on the participant devices and in the operator-hosted store, with the operator-hosted replica protected as in the operator-hosted mode. The participants' storage-mode election, and any subsequent jointly authorized migration between storage modes, is recorded in audit log 170; migration to or from the operator-hosted store transfers only ciphertext and never requires or effects reconstruction of the content key.
4. Key Splitting and Distribution (FIG. 2)
[0020] Referring to FIG. 2, upon completion of capture (or progressively during capture), master content key K (210) is divided (220) under a threshold secret-sharing scheme into shares such that a defined quorum is necessary and sufficient to reconstruct K. In a preferred two-participant embodiment, a two-of-three arrangement is used in a specific configuration: share S1 (230) is encrypted to a device public key of the first participant and stored in the first participant's protected keystore; share S2 (240) is likewise held by the second participant; and share S3 (250) is held by policy server 160, preferably sealed within an HSM or TEE. Critically, the reconstruction policy is configured so that the participant shares S1 and S2 are jointly necessary: reconstruction requires S1 and S2 together with S3, or, in an alternative embodiment tolerating device loss, requires both participants' authenticated approval before S3 may substitute for a lost participant share through an escrowed recovery share released only upon both participants' fresh attestations. In all embodiments, no single entity — participant or operator — holds material sufficient to reconstruct K. After distribution, every assembled or intermediate copy of K is destroyed (260) by overwriting in memory.
[0021] Suitable secret-sharing constructions include Shamir secret sharing over a finite field, additive (XOR) splitting for the strictly-unanimous case, and verifiable secret sharing in which each share carries a commitment enabling any party to verify share integrity without revealing the share. Participant identity keys are asymmetric key pairs (for example, Ed25519 for signatures and X25519 for key agreement) generated on-device at enrollment, with private keys non-exportable from the protected keystore where the platform so permits.
5. Release Policy and Time-Lock
[0022] Policy server 160 associates share S3 with a machine-evaluable release policy established at capture and signed by both participants. The release policy comprises at least: (a) a time-lock condition prohibiting release of S3 before a time t₀ + Δ, where t₀ is the capture time and Δ is a predetermined interval (in one embodiment, thirty days; in another, one year, such that the first permissible viewing coincides with an anniversary of the encounter); (b) a mutual-attestation condition requiring fresh, signed attestations from both participants, each generated within a bounded validity window (for example, ten minutes) preceding the unlock request, affirming present consent to decryption; and (c) a co-presence condition as described below. In an embodiment, the policy further comprises a relationship-status condition in which each attestation includes an affirmation that the participants remain in a continuing relationship, the truthfulness of which is committed to by signature of each participant. The policy is immutable after capture except by a jointly signed amendment, and every evaluation of the policy is written to audit log 170.
[0023] In a hardened embodiment, S3 is sealed such that the policy evaluation itself occurs inside a TEE or HSM whose attested code enforces the time-lock, so that even the operator cannot release S3 early. In a further embodiment, the time-lock is additionally or alternatively enforced by timed-release cryptography, including encryption of S3 to a time-lock encryption service or construction whose decryption capability does not exist before the release time, thereby removing the operator's early-release capability entirely.
6. Joint Unlock Ceremony, Co-Presence, and Liveness (FIG. 3)
[0024] Referring to FIG. 3, decryption is initiated only by a joint unlock request (310) originating from both participants. The policy server verifies the time-lock (320) and the fresh mutual attestations (330). Co-presence and liveness verification (340) then establishes that both participants are contemporaneously present and are live human beings rather than recorded or synthetic imagery. In a preferred embodiment, verification is performed on-device: each participant device performs a biometric liveness check using the device's native biometric framework (for example, a platform face-authentication service backed by a secure enclave), such that no biometric template or image is transmitted to or retained by the operator; the device then emits a signed presence assertion. In a co-located embodiment, co-presence is additionally corroborated by proximity signals between the two participant devices, including Bluetooth Low Energy ranging, ultra-wideband ranging, or exchange of an acoustic or visual nonce (for example, one device displaying a short-lived code captured by the other device's camera). In a remote embodiment, both participants join a live verification video session and each device attests to the liveness of its own enrolled participant.
[0025] Upon satisfaction of all conditions, policy server 160 releases S3 into the unlock session (350). Key reconstruction (360) occurs within a protected environment — in one embodiment within a TEE of one participant device; in another, within a server-side confidential-computing enclave whose attested code performs decryption and streaming without exposing K or plaintext to the operator's general infrastructure. Playback (370) is session-bound: reconstructed key material exists only for the duration of the session, is destroyed at session end, and each subsequent viewing requires a new ceremony. Playback may be marked with a forensic watermark encoding the session identifier, viewing time, and participant identities, so that any out-of-band capture of the displayed content is attributable. The system does not represent that display-layer capture (for example, photographing a screen) is preventable; the security objective enforced cryptographically is that the ciphertext is undecryptable absent the ceremony.
7. Joint Redaction by Cryptographic Erasure (FIG. 4)
[0026] Referring to FIG. 4, during an active joint decryption session (410) the participants may review the recording and jointly designate segments for redaction (420), each designation requiring confirmation input from both participants. The system then produces a redacted copy omitting the designated segments (430), encrypts the redacted copy under a new master key K′ with fresh per-segment keys, and re-splits and redistributes K′ as new shares S1′, S2′, S3′ (440) in the same configuration as at capture. Thereafter the system effects cryptographic erasure of the original: each participant device destroys its original share and returns a signed destruction receipt, and the policy server destroys S3 within its HSM or TEE and emits an attested destruction receipt (450), rendering the original ciphertext permanently unrecoverable (460). In a per-segment variant, redaction is effected without producing a full copy, by destroying only the per-segment key material of the designated segments in all shares, which is more efficient for long recordings. All redaction events, including the identity of the designated time ranges but not their content, are written to audit log 170.
8. Unilateral Cryptographic Destruction
[0027] At any time, before or after the time-lock has expired, either participant may unilaterally direct destruction of the recording (470) by destroying that participant's own key share and issuing a signed destruction directive. Because the participant shares are jointly necessary under the reconstruction policy described above with reference to FIG. 2, destruction of either share alone renders K permanently unreconstructable by every party, including the other participant and the operator. Upon receiving a destruction directive, the system additionally destroys S3 and instructs the counterpart device to destroy its share, and deletes the ciphertext from store 150; however, the security guarantee does not depend on these additional deletions, because the directive-issuer's share destruction is alone sufficient. The operator is technically incapable of overriding, delaying, or reversing a unilateral destruction. This property is intended, among other purposes, to eliminate the possibility of the recording's use as an instrument of coercion following the end of the participants' relationship.
9. Alternative Embodiments and Variations
[0028] The following variations are within the scope of this disclosure, alone and in combination. (a) N-party embodiments: the encounter includes N participants and K is split such that all N participant shares plus the policy share are required, supporting group encounters, ceremonies with witnesses, or family events. (b) In-person capture: the encounter is co-located and recorded by a camera of one or both participant devices or a dedicated capture device, with both-party consent artifacts collected at commencement exactly as in the virtual embodiment. (c) Capture-mode embodiments: the participants jointly elect the capture mode at the consent phase — audio-only, video-only, or audio and video — and the elected mode is recorded in the signed consent artifacts and the audit log; audio-only capture may be elected by participants who consent to an audio record but not a visual record of the encounter. In a further embodiment, during capture either participant may unilaterally downgrade the capture mode (for example, terminating video capture while audio capture continues) or terminate capture entirely, without the concurrence of the other participant; a downgrade or termination takes effect immediately, is recorded in the audit log, and does not affect the encryption or key management of media already captured. (d) Third-party-platform embodiments in which media is obtained through a conferencing platform's real-time media interface with in-platform consent, then encrypted and key-split by the system as described. (e) Escrowed-recovery embodiments in which a recovery share is held encrypted such that it can be activated only by fresh joint attestation of both participants, tolerating loss of a participant device without weakening the unanimity requirement. (f) Anniversary-scheduling embodiments in which the release policy exposes to the participants a countdown but not the content. (g) Estate embodiments in which the participants may jointly pre-authorize, by signed policy amendment, release of the recording to a named beneficiary upon proof of death of both participants. (h) Embodiments in which the encounter is a commitment ceremony, an exchange of wedding vows, a proposal, or a message recorded jointly for the participants' future children, with the same lifecycle. (i) Deployment of the policy server function across multiple independent operators each holding a sub-share of S3, so that no single operator can collude with one participant. (j) Intimate-encounter embodiments: the encounter is an intimate or private encounter between adult partners, designated as such by both participants at capture; in such embodiments, capture is conditioned on a valid age-assurance artifact for every participant as described above, the release policy defaults to requiring co-presence verification for every playback, and the unilateral destruction capability of any participant is non-waivable and may not be disabled by policy amendment. These embodiments are directed to the technical problem that recordings of intimate encounters, consensually created, are conventionally protected only by the continuing goodwill of each custodian, and to providing a technical architecture under which such a recording cannot be viewed, copied, or disclosed by either participant acting alone or by the operator, and can be permanently extinguished by either participant acting alone.
10. Implementation Details of a Preferred Embodiment
[0029] In a preferred embodiment: participant client applications run on iOS, Android, macOS, and the web; identity keys are generated in the platform secure enclave or strongest available keystore; real-time capture uses a WebRTC media server operated by the system with end-to-end-encrypted transport; segments are 10 seconds; per-segment keys are derived by HKDF-SHA-256 from K; segment encryption is XChaCha20-Poly1305; K is 256 bits generated by a cryptographically secure random number generator on the capture server within a TEE; splitting uses Shamir secret sharing over GF(2⁸) with verifiable commitments; shares to participants are encrypted with X25519-based hybrid public-key encryption to each device key; S3 is sealed in a cloud HSM with a policy document evaluated inside an attested confidential-computing enclave; attestations are Ed25519 signatures over a canonical structure containing recording identifier, purpose, timestamp, and nonce; liveness uses the device-native biometric framework with no biometric data leaving the device; co-presence for co-located unlock uses BLE ranging plus a camera-captured visual nonce; the audit log is a hash chain anchored periodically to an external transparency log; and forensic watermarking is applied in the playback path within the enclave.
[0030] The disclosed architecture improves the functioning of the underlying computing system and does not merely implement an agreement between the parties on generic hardware: it provides a specific technical mechanism — jointly necessary key shares, hardware-sealed policy shares, attestation-gated reconstruction inside protected execution environments, per-segment keying enabling selective cryptographic erasure, and receipt-verified share destruction — by which confidentiality and destruction guarantees are enforced against every party to the system, including its own operator, a property that conventional access-control and rights-management architectures do not provide.
Claims
(Included as disclosure; not required in a provisional application.) What is claimed is:
1. A computer-implemented method for controlling access to a recording of an encounter between at least a first participant and a second participant, the method comprising: receiving, from each of the first participant and the second participant, a recorded affirmative consent to recording and a cryptographically signed consent artifact; capturing media of the encounter; encrypting the media substantially at capture under a content key to produce a ciphertext; dividing the content key under a threshold secret-sharing scheme into a plurality of shares comprising at least a first share, a second share, and a third share, wherein the threshold secret-sharing scheme is configured such that the first share and the second share are jointly necessary for reconstruction of the content key; delivering the first share exclusively to a protected keystore of a first device associated with the first participant; delivering the second share exclusively to a protected keystore of a second device associated with the second participant; retaining the third share at a policy server subject to a release policy; destroying all assembled copies of the content key such that no single entity possesses key material sufficient to decrypt the ciphertext; and releasing the third share for reconstruction of the content key only upon determining that the release policy is satisfied, wherein the release policy requires at least: expiration of a predetermined time interval measured from capture of the media, and receipt of a first cryptographically signed attestation of present consent from the first participant and a second cryptographically signed attestation of present consent from the second participant, each attestation generated within a predetermined validity window preceding an unlock request.
2. The method of claim 1, wherein the release policy further requires verification, at a time of the unlock request, of contemporaneous co-presence and liveness of the first participant and the second participant.
3. The method of claim 2, wherein the verification of liveness comprises an on-device biometric liveness determination performed at each of the first device and the second device, and wherein biometric data of the determination is not transmitted from the respective device.
4. The method of claim 2, wherein the verification of co-presence comprises at least one of: wireless proximity ranging between the first device and the second device, and capture by one of the first device and the second device of a short-lived nonce presented by the other of the first device and the second device.
5. The method of claim 1, further comprising, during a joint decryption session authorized under the release policy: receiving, from both the first participant and the second participant, a joint designation of at least one segment of the recording for redaction; producing a redacted copy of the recording omitting the at least one designated segment; encrypting the redacted copy under a new content key; dividing and distributing the new content key in accordance with the dividing, delivering, and retaining steps of claim 1; and thereafter effecting cryptographic erasure of the recording by verified destruction of all shares of the content key.
6. The method of claim 1, wherein encrypting the media comprises encrypting the media as a plurality of time-indexed segments under respective per-segment keys derived from the content key, and further comprising redacting a designated segment by destruction of key material of the designated segment without re-encryption of undesignated segments.
7. The method of claim 1, further comprising: receiving, from either one of the first participant and the second participant, unilaterally and without concurrence of the other participant or of an operator of the policy server, a signed destruction directive; and destroying, responsive to the destruction directive, the key share held for the directing participant, whereby the content key is rendered permanently unreconstructable by all parties including the operator of the policy server.
8. The method of claim 1, wherein reconstruction of the content key and decryption of the ciphertext occur only within an attested trusted execution environment, wherein reconstructed key material is destroyed upon termination of each playback session, and wherein each playback session requires a separate satisfaction of the release policy.
9. The method of claim 8, further comprising applying to decrypted media, during playback, a forensic watermark encoding at least a session identifier of the playback session.
10. The method of claim 1, wherein each attestation further comprises an affirmation that a relationship between the first participant and the second participant is continuing.
11. The method of claim 1, further comprising recording each consent artifact, each evaluation of the release policy, each release of the third share, each redaction designation, and each destruction receipt in an append-only, hash-chained audit log accessible to the first participant and the second participant.
12. The method of claim 1, wherein the encounter comprises a romantic date conducted over a video communication session, and wherein the predetermined time interval is at least thirty days.
13. The method of claim 1, wherein the encounter is co-located and the media is captured by a camera and a microphone of at least one of the first device and the second device.
14. The method of claim 1, wherein the encounter comprises N participants, N being greater than two, wherein the content key is divided such that a respective participant share delivered to each of the N participants is jointly necessary with every other participant share for reconstruction of the content key.
15. The method of claim 1, further comprising retaining an escrowed recovery share activatable, upon loss of the first share or the second share, only upon receipt of fresh cryptographically signed attestations from both the first participant and the second participant.
16. A system for controlling access to a recording of an encounter between at least a first participant and a second participant, the system comprising: a session capture service configured to capture media of the encounter following receipt from each participant of a recorded affirmative consent and a cryptographically signed consent artifact; an encryption engine configured to encrypt the media substantially at capture under a content key and to divide the content key under a threshold secret-sharing scheme into at least a first share and a second share that are jointly necessary for reconstruction of the content key and a third share, and to destroy all assembled copies of the content key; a media store configured to persist only ciphertext of the recording; client applications configured to hold the first share exclusively in a protected keystore of a first device of the first participant and the second share exclusively in a protected keystore of a second device of the second participant; and a policy server configured to retain the third share subject to a release policy and to release the third share only upon at least expiration of a predetermined time interval measured from capture and receipt of cryptographically signed attestations of present consent from both the first participant and the second participant, each attestation generated within a predetermined validity window.
17. The system of claim 16, wherein the policy server comprises a hardware security module or an attested trusted execution environment within which the third share is sealed and within which the release policy is evaluated, such that an operator of the system is incapable of releasing the third share in violation of the release policy.
18. The system of claim 16, wherein the system is configured to receive from either participant, unilaterally, a signed destruction directive and to destroy the directing participant's share responsive thereto, whereby the content key is rendered permanently unreconstructable by all parties including an operator of the system, and to issue a cryptographically verifiable destruction receipt.
19. The system of claim 16, wherein the client applications and the policy server are further configured to conduct a joint redaction session in which segments jointly designated by both participants are omitted from a re-encrypted redacted copy and the content key of the original recording is destroyed by verified destruction of all of its shares.
20. A non-transitory computer-readable medium storing instructions that, when executed by one or more processors of a computing system, cause the computing system to perform operations comprising: receiving, from each of a first participant and a second participant to an encounter, a recorded affirmative consent to recording and a cryptographically signed consent artifact; encrypting media of the encounter substantially at capture under a content key; dividing the content key under a threshold secret-sharing scheme into at least a first share and a second share that are jointly necessary for reconstruction of the content key and a third share; causing the first share to be held exclusively in a protected keystore of a device of the first participant and the second share to be held exclusively in a protected keystore of a device of the second participant; retaining the third share subject to a release policy; destroying all assembled copies of the content key; and releasing the third share only upon at least expiration of a predetermined time interval measured from capture and receipt of cryptographically signed attestations of present consent from both participants, each attestation generated within a predetermined validity window.
Abstract
A recording of an interpersonal encounter is encrypted at capture under an ephemeral content key that is split into shares held separately by each participant's device and by a policy server, with all participant shares jointly necessary for reconstruction. The server share is released only after a time-lock interval and upon fresh signed mutual attestations and verified co-presence and liveness of both participants, with decryption confined to session-bound protected environments and watermarked playback. Participants may jointly redact segments, whereupon a re-encrypted redacted copy replaces the original and the original is destroyed by cryptographic erasure. Either participant may unilaterally and irreversibly destroy the recording by destroying that participant's own share, a capability no operator can override. Access thus requires unanimity while destruction requires only one party, providing technically enforced privacy for sensitive recordings.
Drawings
Four figures (system architecture, key splitting, the joint unlock ceremony, and joint redaction) accompanied the filing draft and are omitted here; the text references to FIG. 1 through FIG. 4 are retained.