# Cryptography and protocol

## Device-bound cryptographic identity

When a device is registered to a Peig workspace, a cryptographic key pair is generated and bound to that device using hardware identifiers unique to the physical machine. The private key never leaves the device. The public key is registered with the workspace.

When an access request is made, the device signs it using its private key. The workspace verifies the signature using the registered public key. This proof-of-device is what grants or denies access — not a password or shared secret.

## Anti-copy protection

Peig uses two layers of protection to detect and prevent key extraction or device identity cloning:

**Static mechanisms** — device-level hardware identifiers that are unique to the physical device and are verified at every authentication. These form a stable fingerprint that ties the cryptographic identity to the specific hardware.

**Dynamic mechanisms** — symmetric cryptographic registers that change with every use and must align between the Peig client and server. If a key were extracted and used on another device, the dynamic registers would fall out of sync — making the attempt detectable.

When a potential copy or cloning attempt is detected, the Access Admin is notified immediately. This applies across all supported platforms.

## The Universal Authentication Cryptographic Protocol

Peig uses the **Universal Authentication Cryptographic Protocol** to bind device identity to access sessions. The protocol:

* Generates device-specific cryptographic credentials at onboarding
* Signs each authentication request with the device's private key
* Verifies the signature server-side before issuing any authentication token
* Binds the resulting session to the originating device

Authentication results are delivered to connected applications using standard identity federation protocols — **SAML 2.0** and **OIDC** — so applications receive a standard signed assertion or token. The device-binding layer is handled upstream by Peig and is transparent to the application.

## Session binding

Sessions issued by Peig are bound to the device that initiated them. Replaying a session token from a different, unregistered device will not grant access. This closes the attack vector of session hijacking — even if a token is intercepted, it cannot be used from another device.

## Data in transit

All communication between Peig clients and the Peig workspace is encrypted in transit using TLS. This applies to:

* Authentication requests and responses
* Identity synchronisation with Microsoft 365 and Google Workspace via their respective APIs
* All admin dashboard communications

## SAML signing

When Peig acts as a SAML Identity Provider for connected services, SAML assertions are cryptographically signed using Peig's IdP certificate. Service providers verify this signature before accepting the authentication result.

Peig's IdP certificate is available in the **SAML IDP Info** section of the Configuration app. It must be configured in each service provider to ensure assertion signatures are validated.

## Client secret management

For Microsoft 365 integrations, Peig stores a client secret that allows it to communicate with Microsoft Graph API for identity synchronisation. This secret has an expiry date set in Microsoft Entra.

{% hint style="warning" %}
Monitor the client secret expiry date. When it expires, identity synchronisation will stop functioning. Generate a new secret in Entra and update the Provisioning configuration in Peig before the expiry date.
{% endhint %}


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.peig.io/welcome-to-peig-documentation/security/cryptography-and-protocol.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.