Hardware-Bound Split-Key Framework for Software Protection Against Reverse Engineering

Scientific Journal of Astana IT University, 2026

Полный текст Открытый доступ: Gold Метаданные (CSL-JSON)
DOI 10.37943/zhxt2203
Достоверность данных 70 средняя
Как считается эта оценка

Складывается из проверяемых признаков самой записи: есть ли у статьи DOI, сколько независимых источников подтвердили её данные, заполнены ли обязательные поля и насколько свежо последнее подтверждение. Снижают оценку расхождения между источниками и отсутствие идентификатора. Значение от 80 означает, что запись опубликована без дополнительной проверки; от 60 до 79 — что она опубликована с пониженной достоверностью и ручная проверка желательна. Запись, выверенную редактором вручную, пересчёт не опускает ниже 90. Это оценка наших данных о статье, а не оценка самой статьи.

Аннотация

Software piracy and reverse engineering cause significant damage to intellectual property: the commercial value of unlicensed software installed worldwide has been estimated at over USD 46 billion. Traditional protection methods rely on static encryption keys or on obfuscation, and they are not resistant to modern analysis techniques such as differential computation analysis (DCA). This study addresses the single point of failure in software protection systems by developing a new key management architecture. The paper introduces a distributed split-key software-hardware framework. A deterministic decryption key is divided into three parts: a local key derived from the unique properties of the machine's hardware (hardware fingerprint), a server key issued after authenticated online activation, and a key sealed in a Trusted Platform Module (TPM) and bound to the platform's Platform Configuration Registers (PCRs). The final key is assembled exclusively in RAM during program execution through an XOR operation and is erased immediately after use. A C#/.NET 8 reference implementation was evaluated on a single Windows platform with a discrete TPM 2.0 module. Changing any of the five hardware identifiers or the PCR state prevented decryption, the assembled key remained in memory for a median of 15.6 µs, key assembly took 0.3 µs, and the one-time TPM sealing took about 67 ms. The runtime overhead stayed below 5% for typical protected functions. The analysis also identifies the remaining limitations of the design: code harvesting through legitimate decryption, binary patching that does not affect PCR 0 and PCR 7, clock rollback during the offline grace period, and loss of access after legitimate firmware or Secure Boot updates. The framework binds execution to authorized hardware and raises the cost of reverse engineering.