Hopr's patented "Codes Hidden In Plain Sight" (CHIPS™) Technology
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.
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.
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.
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.
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.
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).
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.
Assuming an RPC communication protocol is used, the end-to-end encryption provided by CHIPS is performed at the transport layer (layer 4).
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%.
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.
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.
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.
