How we make a
Moving Target

Use Cases

Hopr's patented "Codes Hidden In Plain Sight" (CHIPS™) Technology

One username and password that gets you into all of your accounts and changes everyday.
A secrets manager that is cloud agnostic, rotates secrets as often as you want and update each system immediately.
An employee authentication solution that provides security of MFA with the convenience of SSO with only email.

A special algorithm builds identical keys

The CHIPS™ algorithm is built into a lightweight block of code known as a "sidecar" and attaches to a workload or machine. At the start of a session between two workloads their sidecars run and build an identical secret at each workload.
graphic of two keys and gears

Decryption for identity trust verification

CHIPS secrets rotate at a high frequency. To avoid exposing them in messages (as is typical for authentication), Hopr uses the secrets for end-to-end encryption of messages. Decryption of the message by the receiver verifies trust in the sender.
graphic icon of decrypted document and key

Experts Agree

"Hopr appears to be very powerful"

Global IAM Research Analyst

"This is awesome. You’ve solved for a lot of problems"

DevOps Engineer

"There is nothing like this in the entire world"

CISO, Data Analytics Service Provider

"It's a technology enhancer"

Corporate VP, IAM Product Vendor
image of computer code for hopr's "Codes Hidden in Plain Sight" technology

Watch a recorded demonstration

Click the button below, provide your email address, and watch a 3:13 (min:sec) recorded demonstration of how Hopr's CHIPS technology protects an interaction between two workloads.
Watch the Video

How to build a secret that no one needs to keep

Most "secrets" (tokens, keys) that are used for access to services are built and stored someplace other than where they are needed. Hopr builds them at the workload where they are used, and they vanish when a session is closed.
API Threat Protection Icon
Register with Hopr

Trust of workloads is established once, at registration. Each workload is registered with Hopr and its first session with Hopr anchors the chain of trust in its identity.

motorcycle with sidecar
Obtain a sidecar

Sidecars are pre-configured with a CHIPS algorithm and provided to DevOps engineers as a docker image file. A sidecar is needed for each workload.

app with sidecar
Integrate with a workload and test

The sidecar and workload are installed in the same container. The sidecar runs simultaneously with the workload and and connects to Hopr the first time to verify the operation and trust of the workload.

app with sidecar tested
Go live!

CHIPS technology autonomously protects workloads at every session with another workload, whether it is on-premises, in a commercial cloud, or in hybrid- or distributed-clouds.


Alternate to British "Keep Calm and Carry On" poster. Keep Calm and Automate Security
No key exchange required
Each key stays within the workload where it's built, so it is never exposed.
No secrets storage needed
Ephemeral keys auto-destruct at end of each session and are automatically replaced.
Secure messaging
End-to-end encryption of messages protects data-in-transit over any route.
Decryption verifies trust
Trust in a workload identity is verified by the successful decryption of messages.
No secrets injection
Workloads build their keys and decrypt inbound messages, eliminating the injection of leased secrets that are rotated within secrets vaults.
Works in all environments
Because secrets are built by workloads, CHIPS works in on-premises, commercial cloud, hybird-, or distributed-cloud environments.

Built to convert
and perform

We have been designing and developing high-converting websites since 2015. Our expertise and attention to the details will translate into higher conversion rates and revenue.

How our Moving Target Defense delivers value

Credentials are a prime target for adversaries. Forensics analysts know that adversaries spend 90% of their time in planning an attack and only 10% in the attack. We'll describe how we make credentials fast-moving targets and prevent attacks.
Read Our White Paper
Learn more

Technical FAQ

What synchronizes key generation to ensure identical secrets are produced?

The key generators in each sidecars self-synchronize "on demand" at the start of a session.

The sidecar initiating a session with another workload initiates secrets generation through Hopr’s CHIPS protocol and the responding sidecar generates its secret micro-seconds later.

What happens if sidecars with the same algorithm do not build the same secret?

Without a correct secret decryption of a received message will fail. This could happen on rare occasions due to the transitioning of some dynamic elements used in the CHIPS algorithm.

The failure response is to re-attempt the secret generation (sending a second message with a newly generated secret).

Isn’t CHIPS just another form of time-based one-time passwords (TOTP)?

No.  There may be similarities, but CHIPS does not use time as an input value in secrets generation.

Also, the CHIPS secret is ephemeral rather than “one-time.” Because it is ephemeral, another workload can generate the same secret within a short period of time. TOTP cannot do this.

At what layer of the ISO network stack does CHIPS operate?

Assuming an RPC communication protocol is used, the end-to-end encryption provided by CHIPS is performed at the transport layer (layer 4).

How much overhead does CHIPS add to the operation of Client-Server API calls?

The overhead added by CHIPS occurs only at the start of a session. CHIPS adds 2 messages to the overall message count for each workload.

If two workloads were to interact in a session of 100 API calls and responses, then the additional overhead for the security provided by CHIPS would be 4%.

How much friction occurs with the adoption of Hopr's solution?

Very little friction occurs. No changes to existing applications or APIs are required.

Hopr’s solutions are implemented in the CI/CD pipeline at runtime. The DevOps work is setting a few configuration values and adding a sidecar image file to the container build process.

How does CHIPS encryption differ from mTLS?

End-to-end encryption with CHIPS terminates at a workload container whereas mTLS typically terminates at a server boundary.

CHIPS protects messages over the entire route between two workloads. mTLS cannot do this.

CHIPS encryption is used to verify trust in an identity, mTLS cannot do this.

CHIPS does not rely on PKI certificates or create additional cryptographic material. mTLS does.

CHIPS is simpler to configure an operate and is not vulnerable to credential expiration like mTLS.

Does the CHIPS algorithm provide enough dynamism in the seed for the key?

There is a significant amount of dynamism (variability) in the seed elements used in CHIPS algorithms. It begins with a vast number of URLs where dynamic information can be found, and increases with the many possible locations at an URL.

It increases further because algorithms have many possible structures to alter or modify the dynamic elements. This includes nearly two-dozen variables, each of which has many possible values.

Abstract graphic showing four main components of the XTRA sidecar

Try Our Beta

Apply to participate in our XTRA beta program. XTRA uses CHIPS technology to protect trusted workloads and data.

It's free, and participating enterprises receive benefits that include a bespoke, self-paced, and collaborative experience.
Apply Now