Comparing the Usability of Cryptographic APIs

Y. Acar, M. Backes, S. Fahl, S. Garfinkel, Doowon Kim, Michelle L. Mazurek, Christian Stransky
{"title":"Comparing the Usability of Cryptographic APIs","authors":"Y. Acar, M. Backes, S. Fahl, S. Garfinkel, Doowon Kim, Michelle L. Mazurek, Christian Stransky","doi":"10.1109/SP.2017.52","DOIUrl":null,"url":null,"abstract":"Potentially dangerous cryptography errors are well-documented in many applications. Conventional wisdom suggests that many of these errors are caused by cryptographic Application Programming Interfaces (APIs) that are too complicated, have insecure defaults, or are poorly documented. To address this problem, researchers have created several cryptographic libraries that they claim are more usable, however, none of these libraries have been empirically evaluated for their ability to promote more secure development. This paper is the first to examine both how and why the design and resulting usability of different cryptographic libraries affects the security of code written with them, with the goal of understanding how to build effective future libraries. We conducted a controlled experiment in which 256 Python developers recruited from GitHub attempt common tasks involving symmetric and asymmetric cryptography using one of five different APIs. We examine their resulting code for functional correctness and security, and compare their results to their self-reported sentiment about their assigned library. Our results suggest that while APIs designed for simplicity can provide security benefits – reducing the decision space, as expected, prevents choice of insecure parameters – simplicity is not enough. Poor documentation, missing code examples, and a lack of auxiliary features such as secure key storage, caused even participants assigned to simplified libraries to struggle with both basic functional correctness and security. Surprisingly, the availability of comprehensive documentation and easy-to-use code examples seems to compensate for more complicated APIs in terms of functionally correct results and participant reactions, however, this did not extend to security results. We find it particularly concerning that for about 20% of functionally correct tasks, across libraries, participants believed their code was secure when it was not. Our results suggest that while new cryptographic libraries that want to promote effective security should offer a simple, convenient interface, this is not enough: they should also, and perhaps more importantly, ensure support for a broad range of common tasks and provide accessible documentation with secure, easy-to-use code examples.","PeriodicalId":6502,"journal":{"name":"2017 IEEE Symposium on Security and Privacy (SP)","volume":"136 1","pages":"154-171"},"PeriodicalIF":0.0000,"publicationDate":"2017-05-22","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":"196","resultStr":null,"platform":"Semanticscholar","paperid":null,"PeriodicalName":"2017 IEEE Symposium on Security and Privacy (SP)","FirstCategoryId":"1085","ListUrlMain":"https://doi.org/10.1109/SP.2017.52","RegionNum":0,"RegionCategory":null,"ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":null,"EPubDate":"","PubModel":"","JCR":"","JCRName":"","Score":null,"Total":0}
引用次数: 196

Abstract

Potentially dangerous cryptography errors are well-documented in many applications. Conventional wisdom suggests that many of these errors are caused by cryptographic Application Programming Interfaces (APIs) that are too complicated, have insecure defaults, or are poorly documented. To address this problem, researchers have created several cryptographic libraries that they claim are more usable, however, none of these libraries have been empirically evaluated for their ability to promote more secure development. This paper is the first to examine both how and why the design and resulting usability of different cryptographic libraries affects the security of code written with them, with the goal of understanding how to build effective future libraries. We conducted a controlled experiment in which 256 Python developers recruited from GitHub attempt common tasks involving symmetric and asymmetric cryptography using one of five different APIs. We examine their resulting code for functional correctness and security, and compare their results to their self-reported sentiment about their assigned library. Our results suggest that while APIs designed for simplicity can provide security benefits – reducing the decision space, as expected, prevents choice of insecure parameters – simplicity is not enough. Poor documentation, missing code examples, and a lack of auxiliary features such as secure key storage, caused even participants assigned to simplified libraries to struggle with both basic functional correctness and security. Surprisingly, the availability of comprehensive documentation and easy-to-use code examples seems to compensate for more complicated APIs in terms of functionally correct results and participant reactions, however, this did not extend to security results. We find it particularly concerning that for about 20% of functionally correct tasks, across libraries, participants believed their code was secure when it was not. Our results suggest that while new cryptographic libraries that want to promote effective security should offer a simple, convenient interface, this is not enough: they should also, and perhaps more importantly, ensure support for a broad range of common tasks and provide accessible documentation with secure, easy-to-use code examples.
比较加密api的可用性
潜在的危险密码错误在许多应用程序中都有详细的记录。传统观点认为,这些错误中的许多都是由加密应用程序编程接口(api)引起的,这些接口过于复杂、具有不安全的默认值或文档记录不佳。为了解决这个问题,研究人员已经创建了几个他们声称更可用的加密库,然而,这些库都没有经过经验评估,因为它们能够促进更安全的开发。本文首次研究了不同加密库的设计和可用性如何以及为什么会影响用它们编写的代码的安全性,目的是了解如何构建有效的未来库。我们进行了一项对照实验,其中从GitHub招募的256名Python开发人员使用五种不同的api之一尝试涉及对称和非对称加密的常见任务。我们检查他们生成的代码的功能正确性和安全性,并将结果与他们自己报告的对所分配库的看法进行比较。我们的结果表明,虽然为简单性而设计的api可以提供安全性优势——如预期的那样,减少决策空间,防止选择不安全的参数——但简单性是不够的。糟糕的文档、缺失的代码示例以及缺乏诸如安全密钥存储之类的辅助特性,甚至导致分配给简化库的参与者也在基本功能正确性和安全性方面苦苦挣扎。令人惊讶的是,就功能正确的结果和参与者的反应而言,全面的文档和易于使用的代码示例的可用性似乎弥补了更复杂的api,然而,这并没有扩展到安全性结果。我们发现尤其令人担忧的是,在跨库的20%的功能正确的任务中,参与者认为他们的代码是安全的,但实际上并非如此。我们的结果表明,虽然想要提高有效安全性的新加密库应该提供一个简单、方便的接口,但这还不够:它们还应该(也许更重要的是)确保支持广泛的常见任务,并提供具有安全、易于使用的代码示例的可访问文档。
本文章由计算机程序翻译,如有差异,请以英文原文为准。
求助全文
约1分钟内获得全文 求助全文
来源期刊
自引率
0.00%
发文量
0
×
引用
GB/T 7714-2015
复制
MLA
复制
APA
复制
导出至
BibTeX EndNote RefMan NoteFirst NoteExpress
×
提示
您的信息不完整,为了账户安全,请先补充。
现在去补充
×
提示
您因"违规操作"
具体请查看互助需知
我知道了
×
提示
确定
请完成安全验证×
copy
已复制链接
快去分享给好友吧!
我知道了
右上角分享
点击右上角分享
0
联系我们:info@booksci.cn Book学术提供免费学术资源搜索服务,方便国内外学者检索中英文文献。致力于提供最便捷和优质的服务体验。 Copyright © 2023 布克学术 All rights reserved.
京ICP备2023020795号-1
ghs 京公网安备 11010802042870号
Book学术文献互助
Book学术文献互助群
群 号:481959085
Book学术官方微信