SURAKSHA सुरक्षा

Security Model — Mathematical Trust, No Simulation

v3.3.0

YAKMESH's comprehensive security stack: hardware attestation, KARMA trust tiers, Sybil defense, and the strike system.

KARMA Trust Tiers

Nodes earn trust through verifiable hardware, precise time sources, and sustained good behavior. Trust tiers are named after Nepali expedition team roles:

Tier Nepali Weight Requirements
SIRDAR सिरदार 2.0× Expedition Leader — Atomic clock + AES-NI + 30 days
SATHI साथी 1.5× Trusted Companion — GPS+PPS + AES-NI + 14 days
PATHIK पथिक 1.25× Traveler on Path — PTP + AES-NI + 7 days
YATRI यात्री 1.0× Pilgrim — NTP + AES-NI + 1 day
NAYA नया 0.25× Newcomer — Unverified (new nodes, VMs)
import { TrustProfile, KARMA_TIER, TIER_WEIGHT } from 'yakmesh/security/trust-tier';

const profile = new TrustProfile({ dokoId: nodeId });

// Get node's current tier
const tier = await profile.evaluateTier();
console.log(tier);                    // "sathi"
console.log(TIER_WEIGHT[tier]);       // 1.5

// Check if node meets threshold
if (TIER_WEIGHT[tier] >= TIER_WEIGHT[KARMA_TIER.PATHIK]) {
  // Allow privileged operations
}

Hardware Attestation

Prove you're running on real silicon, not a VM or simulation. AES-NI timing analysis detects emulation.

Real Hardware

  • • AES-NI instructions: ~1-3 cycles
  • • Consistent timing patterns
  • • Low variance across samples

VM/Emulation

  • • Software AES: 10-100× slower
  • • High timing variance
  • • Detectable jitter patterns
import { HardwareAttestor } from 'yakmesh/security/hardware-attestation';

const attestor = new HardwareAttestor();

// Challenge a peer to prove real silicon
const challenge = attestor.createChallenge();
const response = await peer.respondToChallenge(challenge);

// Verify timing proves real AES-NI
const result = attestor.verifyResponse(response);
if (result.isRealSilicon) {
  console.log('Verified real hardware');
} else {
  console.log('Likely VM or emulation');
}

Silicon Parity

"One Silicon = One Vote" — Prevents large server farms from dominating the network.

Weight Division Formula

effectiveWeight = tierMaxWeight / coreCount

A 100-core server gets the same total weight as a single-core Raspberry Pi. This prevents resource-rich attackers from gaining disproportionate influence.

Setup Cores Effective Weight
Raspberry Pi 4 0.50
Desktop PC 8 0.25
Server 64 0.03
100-core farm 100 0.02

Sybil Graph Analysis

Detects coordinated fake identities through network topology analysis.

Clustering Coefficient

Sybil clusters have unusually high clustering (>0.7). Real networks have organic, lower clustering.

Edge Cut Ratio

Insular clusters (<0.1 edge cut) are flagged. Real nodes connect broadly across the network.

Behavior Correlation

Sybils often come online/offline together. Correlated uptime patterns trigger investigation.

Component Isolation

Genuine nodes form one giant component. Sybil clusters are often isolated subgraphs.

Strike System

"Three Strikes — Then Math Speaks" — Progressive penalties for bad actors.

Strike 1: Warning

Fresh start allowed. Strike is recorded against hardware fingerprint.

Strike 2: Probation

7-day probation period. Trust weight reduced to 0.5×. All actions monitored.

Strike 3: Permanent Ban

Hardware fingerprint banned. Cannot rejoin network even with new keys.

Hardware Fingerprint Tracking

Strikes are tied to AES-NI hardware fingerprints, not just keys. Generating new keypairs doesn't reset strikes — the silicon is remembered.

SANGHA — Collective Attestation Layer

SANGHA (v3.3.0) provides continuous collective attestation across all internal components. Six subsystems form a synapse mesh with 15 bidirectional channels.

HARMONIOUS

All components attested. Clean circulation. Normal operations.

CONVERGING

Startup or recovery. Circulation in progress.

DISRUPTED

Anomaly detected. Collective response triggered.

Mesh-Consensus Revocation

Revoke malicious nodes through mathematical consensus, not central authority.

2/3 Threshold Attestation

When 2/3 of trust-weighted peers attest to bad behavior, a revocation certificate is automatically generated and propagated.

  • • All attestations are ML-DSA-65 signed
  • • Revocation certificates are verifiable by any node
  • • No central authority needed

Active Defense Systems

Beyond passive trust scoring, YAKMESH employs active behavioral monitoring to detect and respond to trusted nodes turning malicious.

VEGATI — Velocity Detection

Establishes behavioral baselines using exponential moving averages, then detects sudden changes via z-score anomaly detection. Alerts at 2σ (elevated), 3σ (warning), and 4σ (critical) deviations.

ZIMMEDARI — Attestation Accountability

Tracks attestation accuracy per node. Nodes that file false accusations have their attestation weight reduced. Prevents weaponization of the revocation system.

Trust-Proportional Rate Limiting

Trusted nodes get higher rate limits (up to 5×), but face proportionally harsher penalties if they abuse that trust. Veteran nodes betraying the network are banned 3× longer.

STUPA Emergency Broadcasts

Revocation messages use a special high-priority STUPA channel that bypasses normal rate limits, ensuring rapid propagation of critical security events.

KHATA Trust Protocol

Kryptographic Handshake for Automated Trust Acceptance — The gossip layer for trust information.

Message Types
• ATTESTATION_REQUEST
• ATTESTATION_RESPONSE
• CHALLENGE_FORWARD
• CHALLENGE_RESPONSE
• REVOCATION_ANNOUNCE
• STRIKE_ANNOUNCE
• GEO_PROOF_ANNOUNCE
• LANDMARK_VERIFY

Ternary Integrity Layer

The ternary integrity layer provides 162-trit hierarchical addressing and polynomial-binding commitments. These primitives underpin mesh routing and message authentication.

162-Trit Hierarchical Addresses

162T replaces the legacy 144T scheme with 3×54-trit tiers (Summit / Ridge / Base), delivering 162×log₂(3) ≈ 256.8 bits of true post-quantum security with zero YPC-27 padding waste (54 = 2×27).

SUMMIT
54 trits — global routing
2×27 = zero waste
RIDGE
54 trits — regional routing
2×27 = zero waste
BASE
54 trits — local identity
2×27 = zero waste

Why 162T over 144T?

Metric 144T 162T
Total trits 144 (4×36) 162 (3×54)
Security bits 228.3 256.8
YPC-27 waste 18 trits/chunk 0 (54 = 2×27)
Tier structure 4 tiers of 36 3 tiers of 54
import { TritAddress, TernaryRoutingTable } from 'yakmesh/oracle/ternary-routing';

const addr = TritAddress.generate();     // 162-trit address
const summit = addr.tier('SUMMIT');      // first 54 trits
const ridge  = addr.tier('RIDGE');       // middle 54 trits
const base   = addr.tier('BASE');        // last 54 trits

const table = new TernaryRoutingTable();
table.insert(addr, peerConnection);
const route = table.lookup(targetAddr);  // longest-prefix match

Dual-Layer Trit Commitment

Trit commitments provide non-separable binding between a NIST-standard SHA3 hash and a YPC-27 polynomial checksum. An attacker cannot forge one without invalidating the other.

5-Check Verification Pipeline

1 VERSION_OK — Protocol version matches
2 STRUCTURE_OK — Message envelope valid
3 ADDRESS_DECODED — 162T address parses correctly
4 YPC27_VALID — Polynomial checksum passes cyclic convolution
5 BINDING_VALID — SHA3 ⊕ YPC-27 binding holds

Polynomial Binding

YPC-27 operates in Z[x]/(x27 − 1) mod 3 — cyclic convolution makes the checksum non-separable from the content. Each 27-trit block maps to one polynomial coefficient, and 162T addresses divide evenly into 6 blocks (162 / 27 = 6) with zero waste.

import { TritCommitment, createDualLayerMessage } from 'yakmesh/security/trit-commitment';

// Create a committed message
const msg = createDualLayerMessage(payload, senderAddress162);
// { version, payload, address, sha3Hash, ypc27Checksum, binding }

// Verify on receiving end
const result = TritCommitment.verify(msg);
// { valid: true, checks: ['VERSION_OK','STRUCTURE_OK','ADDRESS_DECODED','YPC27_VALID','BINDING_VALID'] }

// If any check fails, the specific failure is identified:
// { valid: false, checks: ['VERSION_OK','STRUCTURE_OK','ADDRESS_DECODED'], failedAt: 'YPC27_VALID' }