Skip to content

CoreBond/corebond-architecture

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

51 Commits
 
 
 
 
 
 
 
 

Repository files navigation

CoreBond Architecture

Exploration of a hardware-rooted device identity model designed to eliminate stored credentials in IoT authentication systems.

Status

This repository documents the conceptual architecture behind the CoreBond device identity model.

The goal is to explore authentication systems that eliminate stored credentials and traditional key exchange in IoT environments.

This repository focuses on architecture and security model discussion rather than production implementation.

Concept

CoreBond derives device identity from intrinsic physical characteristics of hardware instead of stored credentials.

Goals

  • Remove stored secrets from device authentication
  • Reduce credential extraction risk
  • Simplify trust models in large IoT deployments

Traditional Device Authentication

Most IoT systems rely on stored credentials.

Device → Stored Secret → Authentication Server → Verification

If the secret is extracted, the device identity can be cloned.


CoreBond Concept

CoreBond explores deriving identity from intrinsic physical characteristics of the device rather than stored credentials.

Device → Physical Identity Signal → Verifier → Authentication Decision

No stored secret
No key exchange

Traditional vs CoreBond Authentication

The following diagrams compare traditional stored-credential authentication with the CoreBond identity model.

flowchart LR
subgraph CoreBond Authentication
E[Device Hardware] --> F[Physical Identity Signal]
F --> G[Verifier]
G --> H[Authentication Decision]
end
subgraph Traditional Authentication
A[Device] --> B[Stored Secret]
B --> C[Authentication Server]
C --> D[Verification]
end


Loading

Identity Derivation Process

CoreBond derives device identity from measurable intrinsic hardware characteristics rather than stored credentials.

A device generates a physical identity signal based on intrinsic hardware properties. This signal is observed or measured and evaluated by a verifier.

A simplified process is as follows:

  1. The device hardware produces a measurable identity signal derived from intrinsic physical characteristics.
  2. The signal is observed or measured by the verification system.
  3. The verifier evaluates the observed signal against expected identity characteristics.
  4. The verifier determines whether the device identity is valid.
  5. An authentication decision is returned to the system.

This approach enables device authentication without storing credentials on the device or exchanging secrets with the authentication infrastructure.

The resulting identity signal is deterministic for a given device within defined environmental tolerances.

Device identity may be derived from multiple intrinsic hardware characteristics whose combined measurements form a stable identity signal.

Enrollment Model

CoreBond establishes a baseline device identity during the initial linking of two devices.

When devices are first connected, the verifier observes the intrinsic hardware identity signal and records the resulting identity characteristics. This observation forms the baseline identity profile for the device.

Future authentication decisions compare subsequent identity measurements against this baseline profile.

This enrollment process allows devices to establish trust relationships without pre-provisioned credentials or externally distributed secrets.

Security Assumptions

The CoreBond model assumes the following conditions:

• Device hardware characteristics produce stable, measurable identity signals.
• The verifier can observe or measure these signals with sufficient fidelity.
• Attackers may gain firmware access or limited physical access to a device.
• Attackers cannot easily reproduce the intrinsic physical characteristics of the original hardware.

Threat Model Considerations

CoreBond focuses on architectures intended to reduce risks associated with credential extraction and device cloning.

This model assumes attackers may gain firmware access or physical access to devices and therefore focuses on removing stored credentials that could be extracted and reused.

Security Properties

CoreBond is designed to provide the following security properties:

• Device authentication without stored credentials
• Reduced risk of credential extraction or reuse
• Resistance to device cloning through intrinsic hardware identity
• Simplified trust establishment during initial device pairing • Deterministic device identity within defined environmental tolerances

Limitations

CoreBond does not prevent device compromise if an attacker gains full control of device hardware. The model focuses on preventing credential extraction and device cloning rather than runtime compromise.

About

Exploration of a hardware-rooted identity architecture for IoT devices that eliminates stored secrets and traditional key exchange.

Topics

Resources

Security policy

Stars

Watchers

Forks

Releases

No releases published

Packages

 
 
 

Contributors