Система верифікації фізичних пристроїв DePIN: розробка та аудит

Як працює криптографічна верифікація DePIN?

Припустимо, ви будуєте децентралізовану мережу для моніторингу якості повітря. Сотні фізичних сенсорів розгорнуті по місту, кожен передає дані та отримує токени. Проблема — відрізнити реальний сенсор від програмного емулятора, який шле фейкові показники та спустошує пул винагород. Без криптографічної прив'язки токен-адреси до апаратного модуля будь-який агент може симулювати роботу. Ми вирішуємо це завдання вже понад п'ять років: двадцять з гаком проектів DePIN у продакшені, від IoT-сенсорів до хотспотів. Сумарно обслуговуємо понад 10 000 фізичних пристроїв. Наші клієнти економлять до 90% коштів, які раніше йшли на фейкові нагороди — для мережі з 1000 пристроїв це може перевищувати $50 000 на місяць. Інвестиції в систему верифікації окупаються за рахунок зниження таких втрат.

Ключова складність — три класи атак: Spoofing (емуляція даних), Clone (клонування ключів на безліч машин) та Sybil (масова реєстрація віртуальних пристроїв). Hardware root of trust — єдиний спосіб захиститися. Ця технологія лежить в основі всіх наших рішень для DePIN.

TPM 2.0 (ISO/IEC 11889) — стандарт, в якому приватний ключ ніколи не залишає чіп, підпис формується всередині. Це основа довіри.

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

Spoofing: програмний агент емулює дані — GPS, сенсори, network metrics. Без захищеного ключа на чіпі це невідрізнимо від реального пристрою.

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

Sybil: один оператор реєструє сотні "пристроїв" через віртуальні інстанси. Критично для мереж з винагородою за кількість вузлів. Для анти-сибіл атак ми застосовуємо стейкінг та верифікацію на основі репутації.

Вибір апаратного кореня довіри: TPM, Secure Element або TEE?

• TPM 2.0 (ISO/IEC 11889): приватний ключ ніколи не залишає чіп, підпис всередині. Підтримується в промисловому IoT (Raspberry Pi через GPIO).
• Secure Element (ECC608): виділений мікроконтролер. Використовується в Hotspot від Helium. Детальніше — Secure Element.
• TEE (TrustZone, SGX): ізольоване середовище в процесорі. Дешевше, але вразливе до side-channel.
• PUF: унікальний "відбиток" чіпа — клонувати фізично неможливо. Перспективна технологія.

Як ми будуємо систему верифікації

Provisioning: реєстрація пристрою у виробника

Виробник вбудовує в пристрій Secure Element, генерує ключову пару всередині чіпа (приватний ключ ніколи не вивантажується). Створюється X.509 сертифікат, підписаний CA виробника. On-chain реєструється публічний ключ та відбиток сертифіката.

contract DeviceRegistry { struct Device { address owner; bytes32 certFingerprint; bytes publicKey; uint256 registeredAt; bool active; } mapping(bytes32 => Device) public devices; mapping(address => bytes32[]) public ownerDevices; 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 { 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: регулярна перевірка роботи

Смарт-контракт кожну епоху (наприклад, годину) випускає challenge — випадковий nonce. Пристрій підписує його своїм приватним ключем всередині SE/TEE. Підпис перевіряється on-chain: якщо не збігається — пристрій вважається неактивним, нагорода знижується.

async function issueChallenge(deviceId: string): Promise<Challenge> { const nonce = crypto.randomBytes(32); const timestamp = Math.floor(Date.now() / 1000); await challengeContract.issueChallenge( deviceId, ethers.utils.keccak256(nonce), timestamp + CHALLENGE_EXPIRY ); return { nonce: nonce.toString('hex'), expiry: timestamp + CHALLENGE_EXPIRY }; } 

contract DePINRewards { uint256 constant REWARD_PER_EPOCH = 1e18; uint256 constant EPOCH_DURATION = 3600; struct DeviceStats { uint256 lastChallengeTime; uint256 successfulChallenges; uint256 currentEpoch; uint256 epochChallengesRequired; 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"); uint256 uptime = stats.epochChallengesPassed * 100 / stats.epochChallengesRequired; require(uptime >= MIN_UPTIME_PERCENT, "Insufficient uptime"); uint256 reward = REWARD_PER_EPOCH * uptime / 100; stats.currentEpoch = currentEpoch; stats.epochChallengesPassed = 0; rewardToken.mint(msg.sender, reward); } } 

Proof of Location: античит георозподілу

Для мереж, де важлива географія (сенсори, хотспоти), використовуємо радіо-свідчення (Helium-підхід): пристрій A "чує" пристрій B і підтверджує його присутність. Альтернатива — GPS + TEE з підписом. Атака вимагає фізичної розстановки пристроїв, що дорого.

Staking та Slashing: фінансовий бар'єр для атак

При реєстрації пристрій блокує стейк. При порушенні — слешінг:

• Пропуск challenge -> зниження uptime, менша нагорода
• Clone (дублікат ключа) -> 100% слеш, деактивація
• Фейкові дані -> слеш + manual review

Ми гарантуємо прозорість механізму слешінгу через on-chain логіку.

Що входить в роботу

• Аудит безпеки: аналіз смарт-контрактів та апаратної інтеграції (Slither, Echidna, формальна верифікація)
• Документація: опис протоколу, посібник з інтеграції для виробників техніки
• Firmware SDK: бібліотеки для TPM/SE на Rust/Go
• Деплой та тестнет: розгортання в тестовій мережі, навантажувальне тестування, моніторинг
• Підтримка: річна гарантія на смарт-контракти, консультації з upgrade

Отримайте консультацію з вибору hardware root of trust для вашого проекту.

Покроковий процес розробки

1. Аналітика: визначення моделі загроз, вибір hardware root of trust під бюджет та сценарій.
2. Проектування: архітектура on-chain реєстру, challenge-response, стейкінг.
3. Реалізація: смарт-контракти (Solidity), firmware SDK, інтеграція з апаратурою.
4. Тестування: unit-тести, фаззинг (Echidna), load-test на testnet.
5. Деплой: запуск у mainnet, моніторинг, фіксація багів.

Строки

Повний цикл: від 3 до 4 місяців. Вартість розраховується під ваш проект — зв'яжіться з нами для оцінки.

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

DePIN — нова парадигма, і ми допомагаємо її будувати безпечно. Замовте консультацію для оцінки вашого проекту. Отримайте детальний план архітектури та строків.