{"title":"Session details: Invited Talk II","authors":"Alley Stoughton","doi":"10.1145/3433259","DOIUrl":"https://doi.org/10.1145/3433259","url":null,"abstract":"","PeriodicalId":110751,"journal":{"name":"Proceedings of the 15th Workshop on Programming Languages and Analysis for Security","volume":"8 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2020-11-13","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"115647098","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"Session details: Program Synthesis and Blockchain","authors":"S. Moore","doi":"10.1145/3433260","DOIUrl":"https://doi.org/10.1145/3433260","url":null,"abstract":"","PeriodicalId":110751,"journal":{"name":"Proceedings of the 15th Workshop on Programming Languages and Analysis for Security","volume":"122 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2020-11-13","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"115749327","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"Session details: Invited Talk I","authors":"Marco Vassena","doi":"10.1145/3433257","DOIUrl":"https://doi.org/10.1145/3433257","url":null,"abstract":"","PeriodicalId":110751,"journal":{"name":"Proceedings of the 15th Workshop on Programming Languages and Analysis for Security","volume":"37 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2020-11-13","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"133739836","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"Session details: Types for Gradual Security and Verification of Security Protocols","authors":"Anitha Gollamudi","doi":"10.1145/3433258","DOIUrl":"https://doi.org/10.1145/3433258","url":null,"abstract":"","PeriodicalId":110751,"journal":{"name":"Proceedings of the 15th Workshop on Programming Languages and Analysis for Security","volume":"43 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2020-11-13","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"121095225","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Memory-trace Obliviousness (MTO) is a noninterference property: programs that enjoy it have neither explicit nor implicit information leaks, even when the adversary can observe the program counter and the address trace of memory accesses. Probabilistic MTO relaxes MTO to accept probabilistic programs. In prior work, we developed λobliv, whose type system aims to enforce PMTO [2]. We showed that λobliv could typecheck (recursive) Tree ORAM [6], a sophisticated algorithm that implements a probabilistically oblivious key-value store. We conjectured that λobliv ought to be able to typecheck more optimized oblivious data structures (ODSs)[8], but that its type system was as yet too weak. In this short paper we show we were wrong: ODSs cannot be implemented in λobliv because they are not actually PMTO, due to the possibility of overflow, which occurs when a oram_write silently fails due to a local lack of space. This was surprising to us because Tree ORAM can also overflow but is still PMTO. The paper explains what is going on and sketches the task of adapting the PMTO property, and λobliv's type system, to characterize ODS security.
{"title":"Short Paper: Probabilistically Almost-Oblivious Computation","authors":"Ian Sweet, David Darais, M. Hicks","doi":"10.1145/3411506.3417598","DOIUrl":"https://doi.org/10.1145/3411506.3417598","url":null,"abstract":"Memory-trace Obliviousness (MTO) is a noninterference property: programs that enjoy it have neither explicit nor implicit information leaks, even when the adversary can observe the program counter and the address trace of memory accesses. Probabilistic MTO relaxes MTO to accept probabilistic programs. In prior work, we developed λobliv, whose type system aims to enforce PMTO [2]. We showed that λobliv could typecheck (recursive) Tree ORAM [6], a sophisticated algorithm that implements a probabilistically oblivious key-value store. We conjectured that λobliv ought to be able to typecheck more optimized oblivious data structures (ODSs)[8], but that its type system was as yet too weak. In this short paper we show we were wrong: ODSs cannot be implemented in λobliv because they are not actually PMTO, due to the possibility of overflow, which occurs when a oram_write silently fails due to a local lack of space. This was surprising to us because Tree ORAM can also overflow but is still PMTO. The paper explains what is going on and sketches the task of adapting the PMTO property, and λobliv's type system, to characterize ODS security.","PeriodicalId":110751,"journal":{"name":"Proceedings of the 15th Workshop on Programming Languages and Analysis for Security","volume":"21 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2020-11-09","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"129739313","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
It is easier than ever before to build complex web applications that handle sensitive user data. At same time, regulatory shifts have made data breaches more costly than ever before. While starting Akita, I discovered just how difficult it is for software teams to maintain an up-to-date picture of how sensitive data flows across complex applications. A major challenge is that modern web applications run across many heterogenous components, often communicating via remote procedure calls. Unfortunately, network calls subvert all known software analysis methods for the application layer---and using network tools alone do not yield the full picture. The result is that developers end up piecing the whole story together through reading code, logs, and documentation. At Akita, we observed that network-based application programming interfaces (APIs) are both a root cause of what we call the Software Heterogeneity Problem---and also the key to the solution. The proliferation of APIs for both internal and external use, with the rise of service-oriented architectures and the growth of the API economy, have made it easy to quickly build applications that are amalgams of cross-service network calls. At the same time, there is consolidation around a handful of interface definition languages for web APIs. This makes it possible for us to address the Software Heterogeneity problem by applying programming languages techniques at the API layer. In this talk, I will introduce the Software Heterogeneity Problem and its consequences, demonstrate one way to tackle it at the API layer, and outline API-level security problems I believe we can solve as a community.
{"title":"How APIs Are Both the Illness and the Cure: The Software Heterogeneity Problem in Modern Web Applications","authors":"Jean Yang","doi":"10.1145/3411506.3417602","DOIUrl":"https://doi.org/10.1145/3411506.3417602","url":null,"abstract":"It is easier than ever before to build complex web applications that handle sensitive user data. At same time, regulatory shifts have made data breaches more costly than ever before. While starting Akita, I discovered just how difficult it is for software teams to maintain an up-to-date picture of how sensitive data flows across complex applications. A major challenge is that modern web applications run across many heterogenous components, often communicating via remote procedure calls. Unfortunately, network calls subvert all known software analysis methods for the application layer---and using network tools alone do not yield the full picture. The result is that developers end up piecing the whole story together through reading code, logs, and documentation. At Akita, we observed that network-based application programming interfaces (APIs) are both a root cause of what we call the Software Heterogeneity Problem---and also the key to the solution. The proliferation of APIs for both internal and external use, with the rise of service-oriented architectures and the growth of the API economy, have made it easy to quickly build applications that are amalgams of cross-service network calls. At the same time, there is consolidation around a handful of interface definition languages for web APIs. This makes it possible for us to address the Software Heterogeneity problem by applying programming languages techniques at the API layer. In this talk, I will introduce the Software Heterogeneity Problem and its consequences, demonstrate one way to tackle it at the API layer, and outline API-level security problems I believe we can solve as a community.","PeriodicalId":110751,"journal":{"name":"Proceedings of the 15th Workshop on Programming Languages and Analysis for Security","volume":"21 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2020-11-09","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"124554250","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Types indexed with extra type-level information are a powerful tool for statically enforcing domain-specific security properties. In many cases, this extra information is runtime-irrelevant, and so it can be completely erased at compile-time without degrading the performance of the compiled code. In practice, however, the added bureaucracy often disrupts the development process, as programmers must completely adhere to new complex constraints in order to even compile their code. In this work we present WRIT, a plugin for the GHC Haskell compiler that relaxes the type checking process in the presence of runtime-irrelevant constraints. In particular, WRIT can automatically coerce between runtime equivalent types, allowing users to run programs even in the presence of some classes of type errors. This allows us to gradually secure our code while still being able to compile at each step, separating security concerns from functional correctness. Moreover, we present a novel way to specify which types should be considered equivalent for the purpose of allowing the program to run, how ambiguity at the type level should be resolved and which constraints can be safely ignored and turned into warnings.
{"title":"Short Paper: Weak Runtime-Irrelevant Typing for Security","authors":"Matthías Páll Gissurarson, Agustín Mista","doi":"10.1145/3411506.3417595","DOIUrl":"https://doi.org/10.1145/3411506.3417595","url":null,"abstract":"Types indexed with extra type-level information are a powerful tool for statically enforcing domain-specific security properties. In many cases, this extra information is runtime-irrelevant, and so it can be completely erased at compile-time without degrading the performance of the compiled code. In practice, however, the added bureaucracy often disrupts the development process, as programmers must completely adhere to new complex constraints in order to even compile their code. In this work we present WRIT, a plugin for the GHC Haskell compiler that relaxes the type checking process in the presence of runtime-irrelevant constraints. In particular, WRIT can automatically coerce between runtime equivalent types, allowing users to run programs even in the presence of some classes of type errors. This allows us to gradually secure our code while still being able to compile at each step, separating security concerns from functional correctness. Moreover, we present a novel way to specify which types should be considered equivalent for the purpose of allowing the program to run, how ambiguity at the type level should be resolved and which constraints can be safely ignored and turned into warnings.","PeriodicalId":110751,"journal":{"name":"Proceedings of the 15th Workshop on Programming Languages and Analysis for Security","volume":"69 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2020-11-09","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"124558537","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
A formally verified compiler is a compiler that comes with a machine-checked proof that no bug is introduced during compilation. This correctness property states that the compiler preserves the semantics of programs. Formally verified compilers guarantee the absence of correctness bugs, but do not protect against other classes of bugs, such as security bugs. This limitation partly arises from the traditional form of stating compiler correctness as preservation of semantics that do not capture non-functional properties such as security. Moreover, proof techniques for compiler correctness, including the traditional notions of simulation, do not immediately apply to secure compilation, and need to be extended accordingly. This talk will address the challenges of secure compilation from the specific angle of turning an existing formally-verified compiler into a formally-verified secure compiler. Two case studies will illustrate this approach, where each case study addresses a notion of security and uses modular reasoning (first proving correctness then security) to show that compilation preserves security. Specifically, we consider the problem of secure compilation for CompCert, a formally-verified moderately optimizing compiler for C programs, programmed and verified using the Coq proof assistant [1]. CompCert evolved significantly over the last 15 years, starting as an academic project and now being used in commercial settings [2]. The first case study focuses on software fault isolation and considers a novel security-enhancing sandboxing transformation [3]; it ensures that an untrusted module cannot escape its dedicated isolated address space. The second case study [4] focuses on side-channel protection, and considers cryptographic constant-time, a popular software-based counter- measure against timing-based and cache-based attacks. Informally, an implementation is secure with respect to the cryptographic constant-time policy if its control flow and sequence of memory accesses do not depend on secrets.
{"title":"From Verified Compilation to Secure Compilation: a Semantic Approach","authors":"Sandrine Blazy","doi":"10.1145/3411506.3417601","DOIUrl":"https://doi.org/10.1145/3411506.3417601","url":null,"abstract":"A formally verified compiler is a compiler that comes with a machine-checked proof that no bug is introduced during compilation. This correctness property states that the compiler preserves the semantics of programs. Formally verified compilers guarantee the absence of correctness bugs, but do not protect against other classes of bugs, such as security bugs. This limitation partly arises from the traditional form of stating compiler correctness as preservation of semantics that do not capture non-functional properties such as security. Moreover, proof techniques for compiler correctness, including the traditional notions of simulation, do not immediately apply to secure compilation, and need to be extended accordingly. This talk will address the challenges of secure compilation from the specific angle of turning an existing formally-verified compiler into a formally-verified secure compiler. Two case studies will illustrate this approach, where each case study addresses a notion of security and uses modular reasoning (first proving correctness then security) to show that compilation preserves security. Specifically, we consider the problem of secure compilation for CompCert, a formally-verified moderately optimizing compiler for C programs, programmed and verified using the Coq proof assistant [1]. CompCert evolved significantly over the last 15 years, starting as an academic project and now being used in commercial settings [2]. The first case study focuses on software fault isolation and considers a novel security-enhancing sandboxing transformation [3]; it ensures that an untrusted module cannot escape its dedicated isolated address space. The second case study [4] focuses on side-channel protection, and considers cryptographic constant-time, a popular software-based counter- measure against timing-based and cache-based attacks. Informally, an implementation is secure with respect to the cryptographic constant-time policy if its control flow and sequence of memory accesses do not depend on secrets.","PeriodicalId":110751,"journal":{"name":"Proceedings of the 15th Workshop on Programming Languages and Analysis for Security","volume":"54 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2020-11-09","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"126115898","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Logic Programming (LP) is considered to be relatively simple for non-programmers, and allows the developer to focus on developing facts and rules of a logical derivation, and not on algorithms. Secure multiparty computation (MPC) is a methodology that allows several parties to process private data collaboratively without revealing the data to any party. In this paper, we bring together the notions of MPC and LP, allowing users to write privacy-preserving applications in logic programming language.
{"title":"Short Paper: Secure Multiparty Logic Programming","authors":"A. Pankova, Joosep Jääger","doi":"10.1145/3411506.3417597","DOIUrl":"https://doi.org/10.1145/3411506.3417597","url":null,"abstract":"Logic Programming (LP) is considered to be relatively simple for non-programmers, and allows the developer to focus on developing facts and rules of a logical derivation, and not on algorithms. Secure multiparty computation (MPC) is a methodology that allows several parties to process private data collaboratively without revealing the data to any party. In this paper, we bring together the notions of MPC and LP, allowing users to write privacy-preserving applications in logic programming language.","PeriodicalId":110751,"journal":{"name":"Proceedings of the 15th Workshop on Programming Languages and Analysis for Security","volume":"43 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2020-11-09","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"130849973","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Recent efforts have sought to design new smart contract programming languages that make writing blockchain programs safer. But programs on the blockchain are beholden only to the safety properties enforced by the blockchain itself: even the strictest language-only properties can be rendered moot on a language-oblivious blockchain due to inter-contract interactions. Consequently, while safer languages are a necessity, fully realizing their benefits necessitates a language-aware redesign of the blockchain itself. To this end, we propose that the blockchain be viewed as a typechain: a chain of typed programs --- not arbitrary blocks --- that are included iff they typecheck against the existing chain. Reaching consensus, or blockchecking, validates typechecking in a byzantine fault-tolerant manner. Safety properties traditionally enforced by a runtime are instead enforced by a type system with the aim of statically capturing smart contract correctness. To provide a robust level of safety, we contend that a typechain must minimally guarantee (1) asset linearity and liveness, (2) physical resource availability, including CPU and memory, (3) exceptionless execution, or no early termination, (4) protocol conformance, or adherence to some state machine, and (5) inter-contract safety, including reentrancy safety. Despite their exacting nature, typechains are extensible, allowing for rich libraries that extend the set of verified properties. We expand on typechain properties and present examples of real-world bugs they prevent.
{"title":"Short Paper: Blockcheck the Typechain","authors":"Sergio Benitez, Jonathan Cogan, Alejandro Russo","doi":"10.1145/3411506.3417600","DOIUrl":"https://doi.org/10.1145/3411506.3417600","url":null,"abstract":"Recent efforts have sought to design new smart contract programming languages that make writing blockchain programs safer. But programs on the blockchain are beholden only to the safety properties enforced by the blockchain itself: even the strictest language-only properties can be rendered moot on a language-oblivious blockchain due to inter-contract interactions. Consequently, while safer languages are a necessity, fully realizing their benefits necessitates a language-aware redesign of the blockchain itself. To this end, we propose that the blockchain be viewed as a typechain: a chain of typed programs --- not arbitrary blocks --- that are included iff they typecheck against the existing chain. Reaching consensus, or blockchecking, validates typechecking in a byzantine fault-tolerant manner. Safety properties traditionally enforced by a runtime are instead enforced by a type system with the aim of statically capturing smart contract correctness. To provide a robust level of safety, we contend that a typechain must minimally guarantee (1) asset linearity and liveness, (2) physical resource availability, including CPU and memory, (3) exceptionless execution, or no early termination, (4) protocol conformance, or adherence to some state machine, and (5) inter-contract safety, including reentrancy safety. Despite their exacting nature, typechains are extensible, allowing for rich libraries that extend the set of verified properties. We expand on typechain properties and present examples of real-world bugs they prevent.","PeriodicalId":110751,"journal":{"name":"Proceedings of the 15th Workshop on Programming Languages and Analysis for Security","volume":"110 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2020-11-09","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"131459168","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
京公网安备 11010802042870号
京ICP备2023020795号-1
扫码关注我们
求助内容：
应助结果提醒方式：