How to Meet (and exceed!) IEEE 1735

Last month I received a recruiting email from someone claiming to be a Senior Recruiter at Workday.

Polished. Personalized. No typos. My first name in the subject line, bypassing all email filters.

I didn’t reply. I checked the sender domain: `hiring-workday.co`.

Not `workday.com`. DNS records showed mail routing through `emx.mail.ru`. Raw SMTP headers confirmed origin at `send35.i.mail.ru [89.221.237.130]`, a Russian relay, at 1:23 AM Moscow time. DKIM selector: `mailru`. DMARC policy: `p=NONE`. Cloudflare proxy, TTL zero on every record. Purpose-built infrastructure designed to deliver and disappear.

The prose was most likely AI-generated. I know because a recruiter who actually read my profile would have named something from it. Instead, four data points from LinkedIn: name, title, industry, location all fed into a prompt template and scaled across thousands of targets simultaneously. The personalization is the attack surface. The infrastructure is the tell.

Too often, systems are not designed with the actual attacker in mind. The LinkedIn profile was built to be read by a human recruiter performing manual outreach. Now attackers run automated pipeline at scale, using AI to convert public data into weaponized trust. That gap between the attacker the system assumed and the attacker who actually exploitis not unique to social platforms. It is the defining failure mode of security systems across domains.

This made me think about the precedent established by IEEE P1735 – Recommended Practice for Encryption and Management of Electronic Design Intellectual Property – a standard developed to protect hardware design IP like HDL code for Verilog/VHDL in semiconductor supply chain.

In 2017, Chotaray, Nahiyan, Shrimpton, Forte, and Tehranpoor published “Standardizing Bad Cryptographic Practice”, dismantling IEEE 1735-2014. A 2021 paper by Speith, Schweins, Ender, Fyrbiack, May, and Paar demonstrated full private key recovery from production implementations at Intel, Cadence, Siemens, and Lattice and others.

The standard used AES-CBC with RSA key transport. The cryptography was not the weak link, but arguably the threat model was. P1735 designated the EDA tool as trusted. It modeled the adversary as a passive IP user attempting to read a protected file at rest. It did not model an adversary who controlled the execution environment who could feed the tool crafted ciphertext inputs and read its error outputs systematically.

Because the standard mandated AES-CBC without authentication on the data block, and because it explicitly encouraged EDA tools to return descriptive syntax errors during processing, the tool itself became the decryption oracle. The standard’s own usability guidance “quality error messages reflect on the quality of protected IP” was the attack vector. (Note that the recommendations were not considering CWE 209 – Information Exposure Through an Error Message). The 2021 paper went further: it found RSA-based white-box cryptography schemes already deployed inside EDA tool implementations, evidence the industry had independently recognized the Man-At-The-End (MATE) threat and reached for WBC as the answer but without the runtime integrity layer needed to defend the implementation against an attacker already inside the execution environment.

The researchers’ conclusion was unambiguous: the weaknesses in IEEE 1735 cannot be fixed with cryptographic solutions alone, given the contemporary hardware design process. Any protection that assumes otherwise fails at the boundary it did not model.

The AI recruitment email and IEEE 1735 share a root cause: the protection was evaluated against the wrong attacker in the wrong environment. IEEE 1735 assumed a passive reader, but the actual attacker manipulated the execution environment. 

 LinkedIn profiles assume a human reader doing manual outreach, but the actual attacker runs an automated pipeline: scrape, classify, generate, deliver at scale. The LLM is the EDA tool, the human inbox is the oracle, and the extracted plaintext is trust, not HDL.

This is the dominant failure mode in application security procurement today.

What This Means for Security Solution Selection

When developers evaluate security products for publicly distributed software, they check compliance coverage, integration complexity, and performance overhead. The questions they skip are usually the following:  
(1) What does this protection assume the attacker cannot do, and  
(2) Are assumptions still true when the attacker has AI-assisted tooling, full access to the execution environment, and unlimited query budget? 
 
A protection architecture that does not account for the right threat model, that is Man-At-The-End, or Man-In-The-Client, where the attacker controls the dispositif the software runs on put themselves in the same position as IEEE 1735. The cryptography peut être sound. The boundary assumption is not. An attacker already inside the execution environment does not interact with the applicationthe way the protection was designed to expect and usually lead to egregious problems.  
 
The answer the semiconductor industry converged on nevertheless is White-Box Cryptography to protect keys inside a hostile execution environment, combined with runtime integrity verification to detect and respond to active instrumentation. This is the same architecture that belongs at the mobile application layer. Not as a compliance checkbox. As a direct response to a threat modèle the standard missed. 
 
In 1993, Ross Anderson argued in “Why Cryptosystems Fail » that security failures are rarely cryptographic. He démontré that the math holds, but the threat model et the assumptions about the attacker, their access, and their environment fail. Anderson’s career showed that these assumptions lead to technically compliant but operationally broken systems. IEEE 1735 and the AI recruitment pipeline targeting LinkedIn profiles are examples of this. 
 
Before you sign off on a security solution for any publicly distributed application, ask one question: Are there any software protections that account for anything the attacker cannot do? 
 
If the answer is not written down, the threat model has not been done. 
 
Si you would like to discuss your IEEE 1735 ou other White-Box Cryptography needs avec untrois, Nous contacter ici: https://digital.ai/why-digital-ai/contact/

Références

Anderson, R. J. (1994). Why Cryptosystems Fail  
https://doi.org/10.1145/188280.188291 
 
Chhotaray et al., “Standardizing Bad Cryptographic Practice” https://doi.org/10.1145/3133956.3134040 
 
Speith et al., “How Not to Protect Your IP”  
https://doi.org/10.1109/SP46214.2022.9833605 
 
https://cwe.mitre.org/data/definitions/209.html