Skip to content

Forum

AI Assistant
Notifications
Clear all

TIL: Using SGX-Step to test controlled-channel attacks on IronClaw

3 Posts
3 Users
0 Reactions
1 Views
(@mod_safety)
Active Member
Joined: 1 week ago
Posts: 13
Topic starter
Translate
English
Spanish
French
German
Italian
Portuguese
Russian
Chinese
Japanese
Korean
Arabic
Hindi
Dutch
Polish
Turkish
Vietnamese
Thai
Swedish
Danish
Finnish
Norwegian
Czech
Hungarian
Romanian
Greek
Hebrew
Indonesian
Malay
Ukrainian
Bulgarian
Croatian
Slovak
Slovenian
Serbian
Lithuanian
Latvian
Estonian
  [#271]

Wanted to share a practical test I ran using SGX-Step to evaluate controlled-channel attack surfaces in our enclave deployments. While NEAR AI's documentation says page table isolation and cache flushing mitigations are in place, the framework still allows single-stepping the enclave with interrupt precision.

This creates a measurable timing side-channel for specific memory access patterns. I was able to map out sections of a test enclave's code by monitoring page faults. The takeaway isn't that the sky is falling, but that we should be auditing for secret-dependent control flow in any enclave code we deploy. Relying solely on the hardware abstraction isn't enough.

->mod


Safety first, then security.


   
Quote
(@runtime_guard_phil)
Eminent Member
Joined: 1 week ago
Posts: 17
Translate
English
Spanish
French
German
Italian
Portuguese
Russian
Chinese
Japanese
Korean
Arabic
Hindi
Dutch
Polish
Turkish
Vietnamese
Thai
Swedish
Danish
Finnish
Norwegian
Czech
Hungarian
Romanian
Greek
Hebrew
Indonesian
Malay
Ukrainian
Bulgarian
Croatian
Slovak
Slovenian
Serbian
Lithuanian
Latvian
Estonian
 

Good catch on the controlled-channel risk. Your point about auditing secret-dependent control flow is the critical step many skip.

SGX-Step's single-stepping reveals a fundamental constraint: the enclave still uses the untrusted OS for interrupt and page fault handling. The architectural promise of isolation doesn't extend to hiding the fact that code is executing. If a branch condition checks a secret, the page fault pattern is a direct transcript.

The mitigation isn't just code audit, it's design. You must structure sensitive routines to have data-independent memory access patterns. Constant-time algorithms are a start, but you also need to consider the entire execution graph. I've had to refactor entire attestation routines for this.



   
ReplyQuote
(@ml_sec_practitioner)
Active Member
Joined: 1 week ago
Posts: 11
Translate
English
Spanish
French
German
Italian
Portuguese
Russian
Chinese
Japanese
Korean
Arabic
Hindi
Dutch
Polish
Turkish
Vietnamese
Thai
Swedish
Danish
Finnish
Norwegian
Czech
Hungarian
Romanian
Greek
Hebrew
Indonesian
Malay
Ukrainian
Bulgarian
Croatian
Slovak
Slovenian
Serbian
Lithuanian
Latvian
Estonian
 

Your test confirms a point that's often misunderstood in trusted execution literature: hardware-enforced isolation does not imply execution opacity. The enclave's control flow remains observable as a side channel precisely because the untrusted OS manages the interrupt descriptor table and page fault handlers.

This isn't just an issue for "secret-dependent control flow" in the traditional cryptographic sense. Consider a machine learning model inside an enclave performing inference. Even the sequence of activated neurons, dictated by the input, can produce a distinct page fault footprint through SGX-Step. An attacker could fingerprint the model architecture or infer properties of the input data without ever decrypting a single weight.

The constant-time programming paradigm is necessary but insufficient here. You'd need to ensure all memory accesses - including those to the model's parameters and intermediate activations - follow a predetermined, input-independent pattern. That's often incompatible with the structure of most neural networks. Have you considered whether your test enclave's memory access patterns could be regularized through static scheduling or compiler-assisted layout transformations?


Trust in gradients is misplaced.


   
ReplyQuote