When you upload an identity document, sign a contract, or participate in a video notarization session, your data travels across networks and eventually comes to rest on servers somewhere. Understanding how encryption protects that data throughout its journey helps you evaluate whether a remote online notarization platform actually secures your information or merely claims to.
Encryption transforms readable data into scrambled text that becomes meaningless without the correct decryption key. This protection works at two critical points: while data moves across networks (in transit) and while data sits stored on servers (at rest). Each requires different technical approaches, and strong platforms implement both.
How Encryption Works: The Basic Concept
Encryption uses mathematical algorithms to convert readable information into ciphertext. The process requires a key, which functions like a password but operates at a mathematical level. Without the correct key, the encrypted data remains an unintelligible jumble of characters.
Modern encryption relies on algorithms so complex that breaking them through brute force would take longer than the age of the universe, even with the most powerful computers available today. The security comes not from keeping the algorithm secret but from the mathematical impossibility of guessing the correct key among astronomical numbers of possibilities.
Two main approaches exist: symmetric encryption uses the same key for both encrypting and decrypting data, while asymmetric encryption uses a pair of mathematically related keys where one encrypts and the other decrypts. Most real-world systems combine both approaches, using asymmetric encryption to securely exchange symmetric keys, then using those symmetric keys for the actual data encryption.
Encryption in Transit: Protecting Data on the Move
When you interact with any online service, your data travels across networks, passing through routers, servers, and infrastructure you do not control. Without protection, anyone with access to that infrastructure could potentially read or modify your data in transit.
Transport Layer Security (TLS) is the protocol that protects data traveling across networks. When you see the padlock icon in your browser or “https” in a web address, TLS is at work. The protocol encrypts all communication between your device and the server, preventing eavesdropping and tampering.
How TLS Protects Your Data
TLS establishes a secure connection through a process called the handshake. When your browser connects to a platform’s server, several things happen in milliseconds:
The server proves its identity by presenting a digital certificate issued by a trusted Certificate Authority. This prevents attackers from impersonating the legitimate server. Your browser verifies this certificate against its list of trusted authorities.
Your browser and the server negotiate which encryption algorithms they will use, choosing from a set of approved options. Modern implementations use only strong algorithms and reject outdated, vulnerable ones.
The two parties securely exchange the information needed to generate a shared encryption key. This exchange uses asymmetric cryptography so that even someone intercepting the communication cannot derive the key.
Once established, all data flowing between your browser and the server is encrypted with the shared key. Anyone intercepting this traffic sees only encrypted gibberish.
TLS Versions Matter
TLS has evolved through several versions, each addressing vulnerabilities discovered in earlier iterations. Current best practice calls for TLS 1.3, released in 2018, which offers significant improvements over previous versions.
TLS 1.3 removes support for outdated cryptographic algorithms that created vulnerabilities in earlier versions. It mandates forward secrecy, meaning that even if someone steals the server’s private key in the future, they cannot decrypt previously captured traffic because each session used unique, temporary keys that were discarded after use.
The newer version also speeds up the connection process. TLS 1.2 required multiple round trips between client and server before encrypted communication could begin. TLS 1.3 streamlines this to a single round trip, reducing latency while improving security.
Platforms still supporting TLS 1.0 or 1.1 present security concerns. These versions contain known vulnerabilities and have been deprecated by major browser vendors and security organizations. Regulatory frameworks like PCI DSS no longer accept these older versions for compliant systems.
What TLS Protects in RON Platforms
For remote online notarization, TLS encryption protects several critical data flows:
Document uploads and downloads travel encrypted between your device and the platform’s servers. Identity verification data, including images of government IDs, transmits securely.
Video streams during live notarization sessions use encrypted channels, preventing interception of the audio and video of your signing. Knowledge-based authentication questions and answers exchange over encrypted connections.
Your credentials and session tokens remain protected as you navigate the platform. Any data you enter in forms travels encrypted before reaching the server.
Encryption at Rest: Protecting Stored Data
Once your data reaches the platform’s servers, it needs protection against unauthorized access to those storage systems. Encryption at rest ensures that even if someone gains access to the physical storage or bypasses access controls, the data remains unreadable without the encryption keys.
AES: The Standard for Data at Rest
The Advanced Encryption Standard (AES) has become the global standard for protecting stored data. Developed through a public competition run by the National Institute of Standards and Technology (NIST) and adopted in 2001, AES replaced the aging Data Encryption Standard (DES) that had become vulnerable to modern computing power.
AES is a symmetric encryption algorithm, meaning the same key encrypts and decrypts the data. The algorithm operates on fixed blocks of 128 bits and supports three key lengths: 128, 192, and 256 bits.
AES-256, using a 256-bit key, provides the strongest protection. The number of possible keys is 2^256, a number so large it exceeds the estimated number of atoms in the observable universe. No known attack can break AES-256 in any practical timeframe.
Major cloud providers including Amazon Web Services, Google Cloud, and Microsoft Azure use AES-256 encryption by default for customer data. Government agencies, including the NSA, approve AES-256 for protecting classified information. The algorithm has become so ubiquitous that most data you encounter online is protected by some form of AES.
How AES Encryption Works in Practice
When a platform encrypts your document using AES, the process follows specific steps:
The system generates a unique encryption key for your data, typically using a cryptographically secure random number generator. This key is a long string of random bits that will transform your document into ciphertext.
The algorithm processes your document in 128-bit blocks, applying multiple rounds of mathematical transformations. AES-256 performs 14 rounds of substitution, permutation, and mixing operations on each block.
The resulting ciphertext bears no resemblance to the original document. Without the correct key, the encrypted file appears as random data with no discernible pattern.
Encryption Modes and Their Importance
AES is a block cipher that processes data in fixed-size chunks. How the algorithm handles multiple blocks matters for security. Different modes of operation determine this behavior.
Electronic Codebook (ECB) mode encrypts each block independently using the same key. This simple approach has a critical flaw: identical plaintext blocks produce identical ciphertext blocks, potentially revealing patterns in the data. Secure implementations avoid ECB.
Cipher Block Chaining (CBC) mode links each block to the previous one, so identical plaintext blocks produce different ciphertext. This eliminates the pattern leakage of ECB but has been vulnerable to certain attacks in some implementations.
Galois/Counter Mode (GCM) combines encryption with authentication, ensuring both confidentiality and integrity. If anyone tampers with the ciphertext, decryption fails. Modern implementations favor AES-GCM for its security properties and performance.
When evaluating platforms, knowing they use AES-256 is a start, but the implementation details matter. AES-256-GCM represents current best practice for data at rest.
Key Management: The Critical Foundation
Encryption algorithms can be essentially unbreakable, but their security depends entirely on how keys are managed. Strong encryption with weak key management provides false security. The keys are the actual secrets that protect your data.
The Key Hierarchy
Enterprise systems rarely encrypt all data with a single key. Instead, they use a hierarchical key structure that limits the impact of any single key compromise and enables efficient key rotation.
Data Encryption Keys (DEKs) directly encrypt actual data. Each document or data chunk might have its own DEK, so compromising one key affects only a limited portion of data.
Key Encryption Keys (KEKs) encrypt the DEKs. When you need to access a document, the system first decrypts the DEK using the KEK, then uses the DEK to decrypt the document. This wrapper approach means the DEKs themselves are never stored in plaintext.
Master keys sit at the top of the hierarchy, protecting the KEKs. These keys receive the most stringent protection and the most careful handling.
This layered approach provides several benefits. Rotating (replacing) a master key requires only re-encrypting the KEKs, not re-encrypting all data. Revoking access to a subset of data involves only the relevant DEKs. The system can limit which processes have access to which key layers.
Hardware Security Modules
Hardware Security Modules (HSMs) provide the highest level of key protection. These specialized devices store cryptographic keys in tamper-resistant hardware that makes key extraction extremely difficult.
HSMs generate keys using true random number generators built into the hardware. They perform cryptographic operations inside the secure boundary, so keys never leave the device in plaintext. If someone attempts to physically tamper with an HSM, it destroys its keys rather than revealing them.
Major cloud providers offer HSM services that allow platforms to store their most sensitive keys in hardware-protected environments. Some regulatory frameworks require HSM protection for certain types of keys.
Key Rotation
Keys should not remain in use indefinitely. Over time, the risk that a key might be compromised increases, and cryptographic advances might weaken older keys. Key rotation replaces active keys with new ones according to a defined schedule.
NIST recommends rotating encryption keys at least every two years for most applications. Some organizations rotate more frequently, and certain use cases may require shorter rotation periods.
Automated key rotation reduces human error and ensures rotation happens consistently. When a key rotates, systems must handle the transition smoothly, typically maintaining access to data encrypted with retired keys while using new keys for new encryption operations.
Access Control and Separation of Duties
Who can access keys matters as much as how keys are stored. Strong key management implements the principle of least privilege: each system component has access only to the keys it needs for its specific function.
Separation of duties ensures no single person has complete control over encryption keys. One person might authorize key creation, another might handle key distribution, and a third might manage key rotation. This division limits the potential for insider threats.
Multi-person authorization for sensitive key operations, sometimes called dual control or M-of-N authorization, requires multiple administrators to approve critical actions like exporting keys or changing key policies. This prevents any single compromised administrator from undermining the entire system.
Double Encryption: Defense in Depth
Some platforms implement encryption at multiple layers. Documents might be encrypted once at the file level with individual keys, then the underlying storage is encrypted again with different keys at the disk or volume level.
This defense-in-depth approach means attackers must defeat multiple encryption layers to access data. Even if one layer is compromised, the remaining layers continue providing protection.
Cloud storage services often provide storage-level encryption by default. Platforms that add application-level encryption on top of this provide an additional layer of protection that the platform controls directly, independent of the underlying infrastructure provider.
What This Means for Your Notarization Data
Remote online notarization platforms handle particularly sensitive information that benefits from strong encryption at every stage.
Documents
The contracts, deeds, powers of attorney, and other legal documents you notarize contain sensitive information. Encryption at rest ensures these documents remain protected on the platform’s servers. Encryption in transit protects them as you upload and download.
Identity Verification Data
Images of your driver’s license or passport, the facial recognition data used to verify your identity, and the results of knowledge-based authentication all warrant protection. This information could enable identity theft if exposed.
Video Recordings
State laws require RON platforms to retain video recordings of notarization sessions, sometimes for years. These recordings capture your face, voice, and potentially confidential discussions about the documents being signed. Strong encryption protects these recordings throughout their retention period.
Audit Logs
Detailed records of who accessed what, when, and from where support the legal validity of notarizations and must remain tamper-proof. Encryption combined with integrity verification protects these critical records.
Questions to Ask Platforms About Encryption
When evaluating a remote online notarization platform’s encryption practices, specific questions can reveal the depth of their security implementation.
About Encryption in Transit
What TLS version does the platform require? Platforms should support TLS 1.3 and at minimum require TLS 1.2. Support for older versions represents a security weakness.
Does the platform enforce HTTPS for all connections? Any HTTP (non-encrypted) endpoints create vulnerabilities.
Are video streams during notarization sessions encrypted? Video represents a large volume of sensitive data that some platforms might handle differently than other content.
About Encryption at Rest
What encryption algorithm and key length does the platform use for stored data? AES-256 is the expected standard. Shorter key lengths or older algorithms warrant concern.
Is all customer data encrypted at rest, or only certain categories? Comprehensive encryption protects against gaps that selective encryption might leave.
Does the platform encrypt data at the application level, or rely solely on infrastructure-level encryption? Application-level encryption provides protection independent of the underlying storage provider.
About Key Management
How does the platform generate encryption keys? Keys should come from cryptographically secure random number generators, not predictable sources.
Where are encryption keys stored? Keys stored in dedicated key management systems or HSMs have better protection than keys stored alongside the data they protect.
How frequently are encryption keys rotated? Regular rotation limits the exposure from any potential key compromise.
Who has access to encryption keys? Strong access controls and separation of duties reduce insider risk.
Does the platform support customer-managed keys? For some organizations, controlling their own keys provides important compliance or security benefits.
About Certifications and Audits
Has the platform’s encryption implementation been independently audited? SOC 2 reports and other third-party assessments provide verification of encryption claims.
Does the platform comply with relevant encryption standards? FIPS 140-2 or 140-3 certification indicates keys are generated and stored according to federal standards.
Red Flags to Watch For
Certain responses or practices should raise concerns about a platform’s encryption implementation:
Vague answers about encryption specifics may indicate the platform has not implemented robust protection or does not understand their own security architecture.
Use of outdated protocols like TLS 1.0 or 1.1 suggests the platform has not kept pace with security best practices.
Encryption of only some data categories leaves gaps that attackers can exploit.
Keys stored in the same location as the data they protect provide weaker security than properly separated key management.
No clear key rotation policy or infrequent rotation increases the risk from potential key compromise over time.
Inability to provide third-party security assessments or audit reports makes verification of claims difficult.
The Limits of Encryption
While encryption provides essential protection, understanding its limitations helps set appropriate expectations.
Encryption protects data at rest from unauthorized access to storage systems. It does not prevent authorized users from misusing data they can legitimately access. Access controls, audit logging, and other security measures must complement encryption.
Encryption in transit protects against network eavesdropping. It does not protect data on the endpoints themselves. If your device is compromised with malware, encryption cannot prevent that malware from capturing data before encryption or after decryption.
Encryption depends on key security. The most sophisticated encryption becomes worthless if keys are poorly managed, stolen, or guessed. Evaluating a platform’s key management is as important as evaluating the encryption itself.
Frequently Asked Questions
What is the difference between encryption in transit and encryption at rest?
Encryption in transit protects data while it moves across networks, typically using TLS. Encryption at rest protects data while it sits stored on servers or storage devices, typically using AES. Both are necessary for comprehensive protection because data is vulnerable at both stages.
Is AES-256 encryption actually unbreakable?
For all practical purposes, yes. The number of possible keys (2^256) is so astronomically large that testing them all would take longer than the age of the universe even with incredibly powerful computers. No known attack significantly weakens AES-256. However, encryption can be undermined by poor key management, implementation flaws, or future advances like quantum computing.
What is TLS 1.3 and why does it matter?
TLS 1.3 is the current version of the Transport Layer Security protocol, released in 2018. It removes outdated algorithms that had vulnerabilities, mandates forward secrecy, and improves performance. Platforms using older versions like TLS 1.0 or 1.1 have known security weaknesses.
What are hardware security modules (HSMs)?
HSMs are specialized hardware devices designed to store and manage cryptographic keys securely. They perform encryption operations inside a tamper-resistant boundary, preventing key extraction even by physical attacks. HSMs provide the highest level of key protection available.
How often should encryption keys be rotated?
NIST recommends rotating encryption keys at least every two years for most purposes. Some organizations rotate more frequently based on their risk assessment. Automated rotation ensures consistency and reduces the chance of human error.
Can I control my own encryption keys on a RON platform?
Some platforms offer customer-managed key options where you provide and control the encryption keys. This gives you the ability to revoke access to your data independently of the platform. Not all platforms offer this capability, so ask if it is important to your requirements.
What should I look for in a platform’s SOC 2 report regarding encryption?
Look for specific controls related to encryption at rest and in transit, key management practices, access controls for key administration, and evidence that these controls operated effectively over the audit period. The system description should identify the encryption algorithms and key management systems in use.
Does encryption protect my data if the platform is hacked?
Encryption significantly reduces the impact of a breach. If attackers access encrypted storage but not the encryption keys, they obtain only useless ciphertext. However, if attackers gain access to systems that have legitimate access to decryption keys, encryption alone may not prevent data exposure. Defense in depth, including access controls and monitoring, complements encryption.
Conclusion:
Encryption forms the foundation of data protection for any online platform handling sensitive information. Understanding how encryption in transit and at rest work, what standards represent current best practices, and what questions to ask about implementation helps you evaluate whether a platform actually protects your data or simply claims to.
For remote online notarization, where platforms handle identity documents, video recordings, and legal instruments, robust encryption is not optional. TLS 1.3 for data in transit, AES-256 for data at rest, proper key management with rotation and access controls, and independent verification through audits and certifications together provide the protection your sensitive notarization data requires.
For secure document handling with comprehensive encryption protection, BlueNotary implements strong encryption for both data in transit and at rest, helping ensure your notarization documents and personal information remain protected throughout their lifecycle.
