Разработка системы верификации физических устройств DePIN

Разработка системы верификации физических устройств DePIN

DePIN (Decentralized Physical Infrastructure Networks) — архитектура, где реальное физическое оборудование (сенсоры, роутеры, камеры, майнеры энергии) участвует в децентрализованной сети и получает токен-вознаграждение за предоставляемые услуги. Центральная проблема: как убедиться, что конкретный токен-адрес действительно соответствует реальному физическому устройству, а не симулируется программно?

Проблема верификации физического присутствия

Три класса атак

Spoofing атака: программный агент эмулирует данные физического устройства. GPS координаты, сенсорные показания, network metrics — всё это можно синтезировать. Без hardware root of trust программный spoofing неотличим.

Clone атака: легитимное устройство клонируется — скопированные ключи запускаются на нескольких машинах одновременно. Одна физическая единица вознаграждается множество раз.

Sybil атака: один оператор регистрирует сотни "устройств", которые на деле — виртуальные инстансы на одном сервере. Особенно критично для сетей где вознаграждение зависит от количества узлов.

Hardware Root of Trust

Решение — криптографический материал, который невозможно извлечь из устройства без его физического уничтожения. Производственные подходы:

TPM (Trusted Platform Module): стандарт ISO/IEC 11889. Хранит private key в защищённом энклаве, подписывает attestation reports. Key never leaves TPM — операции происходят внутри чипа. Поддерживается в industrial IoT устройствах (Raspberry Pi 4 имеет опциональный TPM2.0 через GPIO).

Secure Element (SE): выделенный микроконтроллер для криптографических операций. Используется в смарт-картах, eSIM. Helium использует ECC608 SE для верификации Hotspot устройств.

TEE (Trusted Execution Environment): ARM TrustZone, Intel SGX. Изолированная среда исполнения внутри основного процессора. Дешевле отдельного SE, но модель атаки сложнее (side-channel attacks на SGX задокументированы).

PUF (Physically Unclonable Function): уникальный "fingerprint" микросхемы, определяемый случайными вариациями производственного процесса. Нельзя клонировать физически — каждый чип даёт уникальный отклик на challenge. Emerging технология, используется в специализированных IoT чипах.

Архитектура системы верификации

Provisioning (первичная регистрация устройства)

Производитель → Secure Element provisioning
   ↓
Генерация device keypair внутри SE
(private key никогда не покидает устройство)
   ↓
Создание Device Certificate (X.509)
Подписывается CA производителя
   ↓
Certificate chain: Root CA → Intermediate CA → Device Cert
   ↓
On-chain регистрация device public key + cert fingerprint

Производитель подписывает device identity своим CA. Протокол может верифицировать подлинность устройства через cert chain без доверия производителю on-chain — только его CA key нужен в trusted registry.

On-chain Device Registry

contract DeviceRegistry {
    struct Device {
        address owner;           // wallet владельца
        bytes32 certFingerprint; // SHA-256 device certificate
        bytes publicKey;         // public key из SE
        uint256 registeredAt;
        bool active;
    }
    
    mapping(bytes32 => Device) public devices; // deviceId => Device
    mapping(address => bytes32[]) public ownerDevices;
    
    // Trusted manufacturer CA list
    mapping(bytes32 => bool) public trustedManufacturers;
    
    event DeviceRegistered(bytes32 indexed deviceId, address indexed owner, bytes publicKey);
    event DeviceTransferred(bytes32 indexed deviceId, address indexed from, address indexed to);
    
    function registerDevice(
        bytes32 deviceId,
        bytes calldata publicKey,
        bytes calldata deviceCertificate,
        bytes calldata manufacturerSignature
    ) external {
        // Верификация cert chain (упрощённо — полная реализация off-chain)
        bytes32 certFingerprint = keccak256(deviceCertificate);
        
        require(
            verifyManufacturerSignature(deviceId, publicKey, manufacturerSignature),
            "Invalid manufacturer signature"
        );
        
        devices[deviceId] = Device({
            owner: msg.sender,
            certFingerprint: certFingerprint,
            publicKey: publicKey,
            registeredAt: block.timestamp,
            active: true
        });
        
        ownerDevices[msg.sender].push(deviceId);
        emit DeviceRegistered(deviceId, msg.sender, publicKey);
    }
}

Challenge-Response верификация работы

Регистрация — разовое событие. Но устройство должно регулярно доказывать что оно работает и именно это устройство отвечает.

// Smart contract выпускает challenge
async function issueChallenge(deviceId: string): Promise<Challenge> {
  const nonce = crypto.randomBytes(32);
  const timestamp = Math.floor(Date.now() / 1000);
  
  // Записываем challenge on-chain (или off-chain с подписью оракула)
  await challengeContract.issueChallenge(
    deviceId,
    ethers.utils.keccak256(nonce),
    timestamp + CHALLENGE_EXPIRY
  );
  
  return { nonce: nonce.toString('hex'), expiry: timestamp + CHALLENGE_EXPIRY };
}

// Устройство подписывает challenge своим SE private key
// (происходит на устройстве, не в этом коде)
function signChallengeOnDevice(challenge: string): string {
  // TPM2.0 PKCS#11 API:
  // const signature = tpm.sign(challenge, keyHandle);
  return signature;
}

// Верификация on-chain
async function submitChallengeResponse(
  deviceId: string,
  nonce: string,
  signature: string
): Promise<boolean> {
  const device = await deviceRegistry.devices(deviceId);
  
  // Восстанавливаем подписавший ключ
  const recoveredKey = ethers.utils.recoverPublicKey(
    ethers.utils.hashMessage(nonce),
    signature
  );
  
  return recoveredKey === device.publicKey;
}

Proof of Location

Для DePIN сетей где важна географическая распределённость (IoT сенсоры, wireless hotspots):

Radio-based proof (Helium подход): устройства верифицируют местоположение друг друга через radio signals. Witness: если устройство A слышит устройство B на правдоподобном расстоянии — это верификация присутствия. Атака: требует физически расставить устройства в нужных местах, не просто запустить VM.

GPS + TEE attestation: GPS координаты подписываются TEE, которое не может быть изменено без физического доступа. Проблема: GPS spoofing атаки (особенно для outdoor устройств).

Cell tower triangulation + carrier verification: подтверждение местоположения через мобильную сеть. Сложнее spoofить, но требует SIM / eSIM.

Reward механизм с anti-cheat

contract DePINRewards {
    uint256 constant REWARD_PER_EPOCH = 1e18; // 1 token per epoch
    uint256 constant EPOCH_DURATION = 3600;   // 1 hour
    
    struct DeviceStats {
        uint256 lastChallengeTime;
        uint256 successfulChallenges;
        uint256 currentEpoch;
        uint256 epochChallengesRequired; // сколько challenge нужно в эпоху
        uint256 epochChallengesPassed;
    }
    
    function claimReward(bytes32 deviceId) external {
        DeviceStats storage stats = deviceStats[deviceId];
        Device memory device = deviceRegistry.devices(deviceId);
        
        require(device.owner == msg.sender, "Not owner");
        require(device.active, "Device inactive");
        
        uint256 currentEpoch = block.timestamp / EPOCH_DURATION;
        require(currentEpoch > stats.currentEpoch, "Epoch not complete");
        
        // Проверяем uptime в эпоху
        uint256 uptime = stats.epochChallengesPassed * 100 / stats.epochChallengesRequired;
        require(uptime >= MIN_UPTIME_PERCENT, "Insufficient uptime");
        
        // Reward пропорционально uptime
        uint256 reward = REWARD_PER_EPOCH * uptime / 100;
        
        stats.currentEpoch = currentEpoch;
        stats.epochChallengesPassed = 0;
        
        rewardToken.mint(msg.sender, reward);
    }
}

Staking и Slashing

Для увеличения cost of attack: устройство при регистрации должно застейкать токены. При обнаружении мошенничества (duplicate key usage, несоответствие claimed данных реальным) — stake slashится.

Технический стек

Сроки разработки

Фаза 1 (4-6 нед): on-chain device registry, challenge-response протокол, базовый reward механизм.

Фаза 2 (3-4 нед): staking/slashing, anti-cheat оракул, admin tools.

Фаза 3 (4-6 нед): hardware provisioning tooling, firmware SDK для устройств, интеграция с конкретным SE/TPM.

Фаза 4 (2-3 нед): аудит smart contracts, нагрузочное тестирование, testnet deployment.

Полный цикл: 3-4 месяца для production-ready системы. Стоимость зависит от типа hardware и target network.