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.