p≡p – a Conceptional Overview from a Technical Perspective

Because of the wide scope of the project it may be difficult for the new reader to get familiar with p≡p. Therefore, an introduction into a variety of principles and definitions could be helpful, which are commonly used in the p≡p project and by all implementations.

Project Goals

Privacy by Default

The p≡p project has the goal to define and implement all necessary technology to reach the situation that users have Privacy by Default in all technical means. Because in a network environment this goal can only be reached by using cryptographically secured algorithms p≡p has the second goal of enabling the general use of Protected Communication.

Ubiquitous Protection of Communication

Because reaching Privacy by Default is the first goal, when Privacy and Security are conflicting then p≡p always decides for Privacy. However, in most cases these goals do not conflict but implementing Privacy requires implementing Confidentiality and Security. So p≡p can be seen as a Security Project with the aim to provide Ubiquitous Protection of Communication, simultaniously aiming to protect content and meta data.

Protection means Identification, Authentication, Encryption

Communication can only be protected if:

• it is clear who is communicating
• it is clear that communication is coming from the identified source
• the content is authentic and confidentiality is being kept

Therefore, the p≡p project defines and implements measures to always guarantee Identification, Authenticating and Encryption of all communication.

Adding more Privacy

There are legitimate reasons for more privacy. p≡p is defining Identification by Pseudonym as default. All p≡p protocols are aiming to hide Identification information from third party.

There is the option of sending and receiving Anonymized Communication in case Communication Partners do not want to learn about their counterpart, respectively.

Fields adressed by p≡p

The p≡p project is creating IP and market ready products. But this Conceptional Overview is not about business or marketing concerns. In a technical view, the p≡p project is addressing the following fields of interest:

1. Implementation of Cryptography
2. Design and Implementation of Cryptographic Protocols
3. Design and Implementation of Network Protocols
4. Models
5. Design and Implementation of the p≡p engine and the p≡p adapters
6. UX and UI
7. Design of Privacy Preserving Message Formats
8. Implementation of p≡p Plugins for Communication Applications
9. Design and Implementation of p≡p Applications
10. Design and Implementation of Deployment Infrastructure

End-to-End and Peer-to-Peer

All what p≡p does is Peer-to-Peer. There is no central infrastructure for anything p≡p is based on. All Communication is protected End-to-End. Cryptographic protection never breaks, ends prematurely or is incomplete. p≡p is always implemented on the Endpoints.

The User Model of p≡p

A User is a Person, who can appear in a Network at a Network Address. The Identity of a Person is a Network Address the Person is using in a Network. If a User is using multiple Network Addresses these multiple Identities define Pseudonyms. A User can have multiple Identities in the same Network, and a User can have Identities in different Networks. Because a Network Address can be used by multiple Users an Identity is well-defined as pair (User, Adress).

A p≡p instance is representing one Person using one Device. This Person is the Own User of the p≡p instance. Other Users are (possible) Communication Partners.

Multiple Devices, which are used by the same user, can form a Device Group. The p≡p instances of these Devices then synchronize their data using the p≡p Sync Network Protocol family.

If Devices implement Multi User concepts then they can be member of one Device Group for each User they’re supporting. Personal Devices can only be members of one Device Group.

A Message is a text, which is communicated to a Communication Partner. A Message can be expressed in a brief verison, in a verbose version or in a verbose version with mark-up. The brief version of a text is the short message. The verbose version of a text is the long message. The verbose version including mark-up is the formatted version of the long message.

A Message can have Attachments. An Attachment is a binary Document identified by Filename. An Attachment has a Type. The MIME type system is used for Attachments.

A Message has one Sender. The Sender is an Own Identity of the User sending the Message. A Message may have multiple Addressees, which are Identities of Communication Partners. The p≡p security model is based on Sender Identification.

There are Group Identities. A Group Identity is representing a group of Communication Partners instead of exactly one Communication Partner. A Group Identity can be used as Addressee like all other Identities can. Group Identites are not Senders when sending from p≡p instances. Group Identities may be Senders in compatibility mode when a p≡p instance is receiving messages from other implementations.

An Outgoing Message is a Message created and sent by the Own User.

An Incoming Message is recieved by an Own Identity or by a Group Identity where an Own Identity is directly or indirectly member of.

The M2M Model of p≡p

A System is a Software Implementation, whose Network Communication must be protected. The Identity of a System is a Network Address the System is using in a Network. A System can have multiple Identities in the same Network, and a System can have Identities in different Networks.

A p≡p instance is representing one System running on one Device. This System is the Own System of the p≡p instance. Other Systems are (possible) Communication Partners.

Multiple instances of the same System running on different Devices can form a p≡p Cluster. The p≡p instances representing this System on these Devices then synchronize their data using the p≡p Sync Network Protocol family.

If instances of different Systems are running on one Device then for each System they can be member in a different p≡p Cluster.

p≡p specifications and implementations are written for the User Model, with the exception of p≡p plugins and applications dedicated to M2M usage.

To apply specifications and documentation to M2M implementation the terms “User” and “Person” must be replaced by the term “System”.

Basic Cryptographic Model, Patterns, Security Properties

Leveraging dependable Crypto Technology

p≡p is not dependent on a special cryptographic definition or even implementation. Instead, p≡p can be applied to a variety of existing crypto technology. These are the properties a crypto technology has to provide that it can be used with p≡p:

• cryptographically secure authentication
• encryption

I.e. GCM<AES> fulfills these requirements.

In case the full variety of auto-enabling p≡p protocols should be supported then these properties are required, too:

• asymmetric cryptography

I.e. X.509 and OpenPGP fulfill all requirements.

p≡p’s view on Keys, Encryption and Trust

p≡p separates two things consequently:

• actual keydata
• the usage/role of Keys

p≡p is a learning system. It learns about Keys and Identities of Communication Partners by analyzing incoming Messages. The learned information forms the management database. This database is auto-created and updated by each p≡p instance. The current implementation is based on SQLite3, which is used on all platforms. The filename of the management database is management.db. The management database does not contain keydata but information about the usage of Keys and Identities. Keydata is being stored in the implementation of the Crypto Technology the p≡p instance is delivering. In case of Sequoia PGP – p≡p’s recommended crypto implementation – keydata is stored in a SQLite3 database named keys.db.

Each Identity can have a Default Key. This is the Key which is being used as Sender Key in case of Own Identities, and it is being used as Key to encrypt communnication to an Identity otherwise.

In case an Own Identity has no usable Default Key a Default Key is being auto-generated by the p≡p engine.

Communication between an Own Identitiy and an Identity of a Communication Partner is called a Communication Channel.

In case an Identity of a Communication Partner has no usable Default Key communication to this Communication Partner’s Identity will be unprotected. Therefore, the Transport System of the p≡p engine may decide to switch to another Communication Channel to improve Protection. Otherwise, if a usable Default Key is available, Communication will be protected. This is fulfilling the pattern of Opportunistic Encryption.

In case the Default key of an Identity is not set the first Incoming Message from this Identity, which includes a claim for a Sender Key and the usage of this Sender Key as Signing Key as proof, is setting the Default Key. This is fulfilling the pattern of Trust On First Use (TOFU).

Communication Partners are identified by their Identities. An Identity is claimed by Network Address. An Identity is proven by the usage of its Default Key for Sender Authentication. An Identity may be incomplete while this process, because it is not well-defined by Network Address alone. Therefore, the p≡p engine learns User data about Communication partners from the Application. As long as an Identity is not yet well-defined still TOFU is supported. Therefore, the Identity is preliminarly defined by Network Address until more information from the Application arrives. The security properties of TOFU are never violated while this process. But it is possible in case a Network Address is used by multiple decices that Communication is being rated as unprotected even it was perfectly protected until the Application delivers the needed information.

In cases of Asymmetric Cryptography being available in Crypto Tech and where it is unclear if the Communication Partner is correctly informed about the Default Key of the Own Identity being used as Sender Key for an Outgoing Message, this Communication Partner gets a copy of the keydata of the Public Key together with the claim for Sender Key and a Proof that this Key is available to the Sender, so TOFU can take place.

As a result, commonly a p≡p instance sends one unprotected Message to a new Communication Partner attaching the Public Key claiming Default Key, and the Communication Partner answers with a protected Message sending its Public Key for this Identity and claiming Default Key, respectively. This is called the Initial Handshake.

Privacy Preserving Message Formats

p≡p message formats are defined by separating the Outer Message from the Inner Message. The Inner Message contains the transported Message text, Attachments and all meta data, which must be communicated to the Reciepients. The Outer Message is containing all meta data, which is used to transport the Message, together with the protected version of the Inner Message (the crypto text). In this case the Outer Message is the Transporting Message. For unprotected Messages, there is only the Transporting Message. p≡p instances only rate meta data as being trustworthy when it was transported in the Inner Message. The meta data of the Outer Message gets ignored with the exception of pure transport data. Tracing information is removed whenever possible.

p≡p message formats are designed for compatibility wherever this can be reached without risking Security Properties. For example, the p≡p message format for email is backwards compatible to PGP/MIME. The p≡p standard message format for Financial Messages is fully compatible to ISO 20022.

Because format ambiguity always opens Attack Vectors, p≡p message formats are defined with the goal of avoiding all ambuguity as much as possible.

In-band Protocols and Out of Band Protocols

p≡p is supporting the Protection of Communication where keydata and p≡p protocol information can be communicated In-band by Tunneling through the very Message flow, which is being protected by p≡p. In this case keydata and p≡p protocol messages are being sent as Attachments by default. For example, this is implemented for email and for Financial Messages, which are based on XML like ISO 20022.

p≡p is supporting the Protection of Communication, too, where keydata and p≡p protocol information can be communicated In-band but an Attachment concept is not feasible. In this case the p≡p protocols are being transmitted with extra Messages. For example, this is implemented for MT-FIN.

p≡p is supporting the Protection of Communication where no In-bound usage of Communication for the p≡p protocols is possible. In this case the p≡p protocols are being transmitted on a Management Channel. For example, this is implemented for IPsec.

p≡p Management Protocols

All other protocols for managing identities, keys and trust are defined in Finite State Machines (in case they’re stateful) and ASN.1. There are three families of peer-to-peer network protocols in p≡p:

p≡p Sync

p≡p Sync defines the network protocols, which are used to keep Devices of a Device Group in Sync. The p≡p KeySync protocol is implementing formation of a Device Group by secure auto-discovery. The p≡p TrustSync protocol is keeping Trust Information in sync. There are further protocols planned for synchronizing user data.

p≡p Distribution

p≡p Distribution defines network protocols, which organize communication between p≡p instances of Communication Partners. p≡p KeyReset organizes Key Replacement and Key Revocation. p≡p Exploration organizes Identity mapping to Users, which is meant to be uncovered for particular Communication Partners. p≡p ManagedGroup organizes cryptographical information for Group Encryption, the encryption for Group Identities.

p≡p Storage

p≡p Storage defines MessageStorage, which organizes secure storage of Rating information and Messages in insecure Storage environments.

Basic Architecture of p≡p implementations

p≡p has a Three Tier Architecture:

• Application
• Adapter
• Engine

The p≡p engine implements the p≡p protocols. It implements a Rating Engine calculating the Privacy Status for Messages and Channels. The p≡p engine connects to Crypto Technology and provides the p≡p API and the Adapter API.

The p≡p adapters provide access to the p≡p engine in a Development Culture. A Development Culture includes one or more a Programming Languages, Best Practice and a Development Environment. p≡p adapters clean user input and provide the p≡p API and other APIs to the application developer in the safest way possible.

The p≡p plugins and applications implement p≡p protected communication using p≡p message formats. They are presenting the p≡p Privacy Status to the User.

Where to go from here?

This is depending on your interest ;-) For more technical things you can try the provided information in the very Wiki you’re reading already. For UX topics you can try the Design Reference Base. A couple of protocols and definitions led to Drafts for RFCs. p≡p security have beautiful User Documentation for the User’s point of view. And, because p≡p is Free Software, you can have a look on Sequoia PGP, on the source code of all what p≡p foundation does and on the source code being published by p≡p security, including the full source code of the apps they’re creating.

Welcome to p≡p!