How Does Automated Encryption Key Management Work?

Of all the technologies to emerge in recent years, encryption and automation stand out as the all-stars in terms of cross-industry appeal. They also happen to be the two that stand to have the biggest impact on your organization’s data security. With the rise in data breaches, increasing instances of business email compromise attacks, and global concerns over big data—security has never been on more people’s minds.

Not only keeping your organization’s proprietary information secret, but also assuring your clients that their data is safe in your hands, is imperative in this climate. Encrypting communications is a crucial piece of that puzzle, as is automation. That last may seem surprising at first, but once you know that Gartner estimates as much as 95% of cloud data breaches result from human error—it makes sense. Right now, encryption key management is a huge source of manual effort, which means it’s a significant vector for human error. But what if it didn’t have to be? What if you could automate the handling of encryption keys and thus reduce the possibility of lost and expired keys, misconfigured security practices, and costly, overlapping key storage tools? To us, that would be a no-brainer. But before we dive into the nitty-gritty of how p≡p does just that, let’s look at a brief overview of p≡p and how it works.

Ease of Installation

Encryption and automation may be exactly what you need to lock down your data, but what good is any technology if people don’t use it? Encrypted transmissions are the ideal we’re going for, but if the encryption tool is a pain to install and/or counter-intuitive to use, how many will opt out and just keep sending plain text messages that contain vital company information?

Because p≡p operates on a peer-to-peer model, there is no centralized key store or encryption server to install. Everything is conducted by the application once installed and configured on the client device, be it a Windows desktop, Mac laptop, iPhone, Android tablet, or even Linux server (in the case of SWIFT transmissions). The install process itself (on an email client, at least)  looks identical to that of any end-user software with a guided install that accounts for no more than 5 clicks and approximately two minutes.

Specific install guides are available for the most common scenarios:

p≡p for Outlook

p≡p for iOS

p≡p for Android

p≡p for Thunderbird

p≡p Architecture Basics

p≡p‘s concepts are the same for financial messaging (e.g. SWIFT) and email. That said, some functions will differ from one implementation to the other. For example, p≡p for financial messaging uses the same JNI Adapter used in other p≡p implementations. On the other hand, p≡p for financial messaging provides some features, that for instance do not exist (nor make sense) in p≡p for Email. These features might, for instance, support the existing IT environment in banking. In p≡p’s technology, this functionality is independent of the specific financial messaging solution being used. This means that a proprietary, vendor-based system can run p≡p just as easily. All you need is the p≡p Enterprise Toolkit (ETK) to facilitate installation and configuration across all possible scenarios.

p≡p has a three-layer stack: p≡p Engine, p≡p Adapters, and p≡p Applications. Between

every two layers are interfaces that are described as protocols. p≡p’s core is the p≡p Engine, which works in the same way across platforms. In the layer above the p≡p Engine, the p≡p Adapters are used to build p≡p plugins and connect to the p≡p end-user Apps. For example, there is a native app for iOS that accesses the p≡p Engine via the Objective-C/Swift Adapter. More information about p≡p’s functionalities and general architecture can be found here.

p≡p Engine

The p≡p Engine is the core component of every p≡p-enabled application. The engine includes the library, which applies cryptography to messages (including compatibility with OpenPGP), manages keys, handles trust, and drives message transports. It encapsulates the complex security functionality necessary to engage in the p≡p protocols. The p≡p Engine does this by isolating much of the security-critical code in a single internal component. The p≡p Engine isn’t used in the application code directly but interfaces with, for example, with p≡p Connector, the p≡p Plugin and the p≡p Proxy via the p≡p JNI Adapter. In order to ensure backward and forward compatibility on the widest variety of platforms, the p≡p Engine is written in C99 and currently runs on Android, iOS, Linux, macOS, and Windows, as well as z/OS on a mainframe. The p≡p Engine is highly portable and can run on minimalistic hardware.

In other words, this is where the magic happens. I.e., this is how we’re able to power:

  • Encryption Services
  • Identity Management
  • Fully Automated Key Management
  • Trust Management
  • Additional Message Transports
  • Anonymization

It’s at the heart of our unique solution--the only question is how to connect that functionality to the systems that actually need it.

p≡p Adapters

The p≡p adapters allow applications to interface with the p≡p Engine. A simple API allows for easy integration in many languages and development environments. As a result of this multi-tier architecture, users can develop add-ons, plug-ins, apps, and any other front-end solution to make use of p≡p’s cryptographic functionality without having to deal directly with the cryptographic engine. The interfacing adapter does the job for you. Currently, the following adapters exist:


Supported Languages


Java (eg: for financial messaging and Android)

COM server

C#, C++,



Objective C

Swift (iOS/macOS)




C++, Qt

p≡p Applications

As a result of this separation of p≡p Engine, Adapters, and Applications, p≡p delivers a flexible architecture suitable for any applications--meaning that it can be used for anything from email to SWIFT messages and beyond. Like we said above, p≡p offers some end-user apps for email:

Since these are already purpose-built for the relevant environments, they save your developers the trouble of creating new code to connect to the p≡p Engine.

Automated Key Management

Automated key management is one of the fundamental aspects of the p≡p encryption solution. By taking this task out of the hands of fallible humans, we can eliminate a major source of data breaches. p≡p has separated the management of keys (“Do I have the key material?”) from the transmitting of key material (“What key material do I use to encrypt?”), which allows p≡p to function no matter the precise way in which the key material appears. However a key comes, p≡p will import it: thus, any public key that’s sent along with a messages is automatically taken in by our system and then used as needed--provided it meets our standards for strong cryptography.

Essentially, when a message comes in or goes out, p≡p performs encryption and decryption automatically using the key material that’s present. With outgoing messages, the reverse happens. By interfacing with the p≡p engine, the various p≡p adapters and apps are able to continually update a key management database that features automatic management of each of the elements we’re discussing. Within that database, different keys are assigned different roles:

  • OwnKey: Referring to a single (the own) system in the management.db
  • DefaultKey: Referring to an Identity or System in the management.db
  • Sender’s Key: Since p≡p is fully peer-to-peer, the Sender’s Key is referring to one specific message of a communications partner (public key).

p≡p uses a TOFU (trust-on-first-use) approach, in which the initial message transmitting necessary key material is unencrypted, and subsequent messages are encrypted opportunistically. Each Identity refers to one DefaultKey. Identities, rather than keys themselves, are assigned addresses, such that trust can be established with a particular system. Of course, this all happens behind the scenes, while the users enjoy ongoing message protection.


  • p≡p’s DefaultKeys can be private or public, are used to encrypt and decrypt data on devices, and are short-living (lifespan can be set during configuration).

Selecting and changing the DefaultKey

For those of you who might want more in the way of technical nitty-gritty--here it is:

In case there is no DefaultKey for an own identity an OwnKey is generated becoming its DefaultKey. The Sender’s Key, which at first passes the TOFU protocol (Trust On First Use, cf. also further below) for a comm_partner’s identity, becomes the DefaultKey of this identity. KeyReset triggers changing the DefaultKey if the comm_partner sends a KeyReset message.

How p≡p deals with keys implicitly and explicitly:

Part of the elegance of the p≡p system is its ability to both take in key material and generate its own in a way that’s totally opportunistic. For Implicit key management, this involves:

  • Generating own keys
  • Receiving and learning about comm_partner’s public keys
  • Trust-On-First-Use (TOFU) principle
  • Handshake protocols
  • Sending and declaration of Sender’s Key (public part of it) and DefaultKey for comm_partner identities

For explicit key management, the system has additional functionality:

  • p≡p Sync (for key management inside a device group):
  • KeyReset (for resetting keys as needed)

But, again, your average email user doesn’t need to be aware of any of this. Even for financial messaging, an admin doesn’t need to delve too deeply into these details--which is critical, because it reduces that risk that something will go wrong and you’ll fall victim to a cyber attack.

Automated encryption is the best way we know of to manage the risks associated with data breaches and business email compromise-style attacks. To shrink your attack surface as much as possible, you need to remove the human error factor. Encrypting all data transmissions is the only way to ensure your company is never affected by phishing attacks, and it can help mitigate the impact of social engineering by alerting users to the presence of spoofed accounts.

By eliminating key management as a task that employees and admins have to deal with, you’re eliminating far more than that—i.e. the most common attack vectors from BEC, to  MITM, to the various forms of social engineering that are used to coerce valuable information out of unsuspecting and otherwise trustworthy employees. p≡p deals with this by using a peer-to-peer model, where all encryption and decryption, as well as all aspects of key management, are handled by p≡p applications at the relevant endpoints. This renders your encryption keys safe and well-managed, your employees nonculpable, and your data secure.

Contact Us for More Insights

Contact Us