Memory-Safe Elimination of Side Channels

Abstract

Agradeço ao professor Luís Fabrício Wanderley Góes, meu orientador durante a graduação. Foi por meio dele que passei a conhecer o professor Fernando Magno Quintão Pereira, que hoje é meu orientador no mestrado. Ao professor Fernando, por todo o suporte e por todos os ensinamentos durante estes últimos dois anos. É, certamente, uma grande fonte de inspiração, como pesquisador, professor, orientador e como pessoa. Sem ele, nada do que foi desenvolvido neste projeto seria possível. Aos meus colegas do Laboratório de Compiladores (LaC), pelas experiências tanto profissionais quanto pessoais. Em especial, ao Michael Canesche, que teve participação direta e foi de suma importância para a realização dos experimentos apresentados neste trabalho. A todos os professores, tanto atuais quanto passados, que contribuíram para que pudesse chegar até aqui. Por fim, agradeço ao Conselho Nacional de Desenvolvimento Científico e Tecnológico (CNPq), pelo suporte financeiro dado ao longo destes dois anos. "I'm not crazy. My mother had me tested."(Sheldon Cooper) ResumoUm programa é dito isócrono se seu tempo de execução não depende de informações sensíveis. Isocronicidade é uma propriedade essencial em implementações criptográficas, posto que programas isócronos não apresentam vazamento de informações relacionadas a seus tempos de execução. Nesta dissertação, nós demonstramos como adaptar para o contexto de resistência à canais laterais um algoritmo de linearização parcial de grafos de fluxo de controle que foi, inicialmente, concebido para maximizar o desempenho em programas vetorizados. Esta transformação é correta: dada uma instância das entradas públicas, o programa parcialmente linearizado sempre executa a mesma sequência de instruções, independente das entradas secretas. Caso o programa original seja publicamente seguro, os acessos à cache de dados serão indistinguíveis no código transformado. Esta transformação é, também, ótima: todo desvio dependente de dados secretos é linearizado; nenhum desvio que dependa apenas de dados públicos é linearizado. Assim, a transformação preserva laços que dependem de informações públicas. Se todos os desvios que saem de um laço dependem de dados sensíveis, o programa modificado não terminará. Nossa transformação estende trabalhos recentes de maneiras não triviais. Ela é capaz de lidar com construções como "goto", "break", "switch" e "continue", que não estão presentes na linguagem de domínicio específico FaCT (2018). Assim como a ferramenta Constantine (2021), nossa transformação garante invariância de operações, mas sem necessitar de informações provenientes da execução dos programas. Além disso, em contraste com SC-Eliminator (2018), nossa técnica é capaz de lidar com programas contendo laços sem limites conhecidos em tempo de compilação.

Constantine: Automatic Side-Channel Resistance Using Efficient Control and Data Flow Linearization

“…These numbers only increase to 16% and 68% for word-level protection. Our SCE suite numbers are comparable to those of SC-Eliminator [78] and Soares et al [60] (which we confirmed using the artifacts publicly released with both papers, Appendix G), despite Constantine offering much stronger compatibility (i.e., real-world program support) and security (i.e., generic data-flow protection and no decoy path side channels) guarantees. On the Raccoon test suite, on the other hand, Raccoon reported two orders-of-magnitude slowdowns (up to 432x) on a number of benchmarks, while Constantine's worst-case slowdown in its default configuration is only 1.84x, despite Constantine again providing stronger compatibility and security guarantees (i.e., no decoy path side channels).…”

“…The just-in-time strategy to linearize secret-dependent unbounded control flows (loops) allows us to dodge intractability with high bounds and code bloat with tractable instances [60]. For points-to set identification and indirect call promotion, our analyses yield very accurate results (i.e., closely matching the run-time accesses) on the programs we consider.…”

“…• 23 realistic crypto modules manually extracted by the authors of SC-Eliminator [78] from a 19-KLOC codebase (SCE suite), used also in the evaluation of Soares et al [60]; • 6 microbenchmarks used in the evaluation of Raccoon [52] (Raccoon suite)-all we could recover from the source code of prior efforts [41,42]-using the same input sizes; • 8 targets used in constant-time verification works: 5 modules of the pycrypto suite analyzed in [76] and 3 leaky functions of BearSSL and OpenSSL studied in Binsec/Rel [20]. For profiling, we divide an input space of 32K elements in 128 equal partitions and pick a random instance from each, producing a profiling input set of 256 inputs.…”

“…To address this problem, much prior work has proposed solutions to automatically transform programs into their constant-time equivalents or variations [27, 28, 34, 36, 41-43, 45, 49, 57, 63, 65, 71, 73, 75, 82-85]. Unfortunately, even the most recent solutions [52,60,78] offer limited security or compatibility guarantees, hindering their applicability to real-world programs.…”

“…Moreover, this form of predication hampers the opti-mization process of the compiler, forcing the use of pervasive cmov instructions and constraining code transformation and generation. Some more recent solutions attempt to generate more optimized code by allowing some [60] or all [78] accesses on unmodified addresses on decoy paths. However, this hybrid strategy mimics transactional execution behavior and is similarly vulnerable to sidechannel attacks that detect data-flow invariant violations on decoy paths.…”