[Music]
welcome back
now we have lindsey homewood who is here
to tell us how to make users of your
cryptographic library successful
lindsay is a product and engineering
manager
uh working at cypher stash as the lead
or the chief product officer
previously served as the head of
technology at the australian federal
government's digital transformation
agency
he also won third prize at the 1996
sydney royal easter show lego building
competition
lindsay will endeavour to allow time at
the end of his
presentation for questions so please
leave your questions in the
question tab
over to
lindsay
great thank you so much greg for that
lovely introduction and uh just a big
shout out and thank you to all of the
organizers as well who have been
involved in in putting this production
on it's pretty amazing to watch behind
the scenes uh you know how much effort
and and hard work they're putting in to
to create an experience like this so
big uh big hat tip to all of you
so my name is lindsey homewood i am the
chief product officer at cypher stash
where we are trying to build
uh a new searchable encryption
technology uh commercializing that uh
and so a big part of my job is focused
on how do we actually make the
cryptography technology that we're
building uh usable by our users
and uh in a product role uh typically uh
you can go out and you can do you know a
you know maybe a less technology focused
company
you do a lot of interviews with users
but it's a bit of a different sort of
set of challenges i guess when it comes
to working with developers and looking
at how they're writing code and how
they're using the code that we're
writing and shipping to our users so i
spend a lot of time looking at academic
research about
cryptography cryptography usability
overall and fortunately this intersects
really really well with open source
because pretty much all of the research
that we've had into cryptography the
security and the usability side of it is
based around open source technologies so
i've read probably close to 50 papers in
the last couple of months about uh open
source cryptography and the usability of
that and what i'm going to be doing
today is sort of taking you stepping you
through sort of the highlights and the
low lights of it
in case you're wondering about what what
the hell a foot gun is um it's sort of
like an old unix sort of program a joke
of
it's a feature that is likely to shoot
users in the foot
which obviously we don't want to do when
we're when we're doing cryptography and
helping people be successful with the
libraries that we're building
but before i start i would like to
acknowledge the traditional owners and
custodians of country throughout
australia which in my case is the dark
and young people and recognize their
continuing connection to land waters and
culture we pay our respects to their
elders past and present sovereignty has
never been seeded and trees have never
been signed it always was and always
will be aboriginal land
so cast your mind back to
2020 um you might not want to because 20
things have not been great since 2020
but um let's talk about something
particularly dark that happened in 2020
you might not be aware of if you thought
it was bad already just wait you to hear
about this so there was a health tech
startup in finland named vestamo that
suffered a fairly significant data
breach so they had over 300 000 patient
records leaks and those were including
detailed consult notes written by a
psychologist or psychiatrist during
during a session with a patient and this
information was leaked on the internet
and actually used to extort patients of
this particular service
so this had a really
tangible human impact on the people that
were involved in this data breach
so this particular person from this
article i highly recommend you give it a
read from william ralston in wyatt
this particular person got a message on
on snapchat saying hey your data isn't
is in this massive breach um and this is
from uh when he used uh vestamos
services uh a couple of years prior but
hadn't hadn't been using it so you know
these are these are people that have had
significant trauma in their life and
significant mental health issues and
this information was just leaked right
out there um and the uh the people that
did this took one step further they
actually were blackmailing people and
saying hey you need to pay us a bit of
bitcoin uh for us to permanently delete
this information in the data breach that
we've uh that we've that we've just done
so a pretty bad situation overall
um and when the researchers and the
incident responders dug into it
afterwards
um there was a pretty glaring flaw in
the end in their entire system which is
it didn't encrypt
any of the data at all in fact it was
just a plain old i believe was a mysql
database uh with a with a php based
weber
and yeah just some very basic network
access controls
but you know there was no encryption in
the mix in any of this
and you're probably thinking now wow
that's pretty messed up but i would
never do this because i am smart and
intelligent and i am at a conference
like this like lca and taking time out
of my weekend
and i would i would never if i was put
in a position to to build and design a
system such as this i would i would
never uh build it in this way that i
wouldn't use any encryption
and
the problem with this is it doesn't
really matter what your intentions are
in this particular study which we're
going to talk about a little bit later
that was comparing the usability of
different cryptographic apis uh the
researchers found that uh in these
programming exercises where they had
people uh writing python to encrypt and
manage data they found that 20 of the
submitted code was insecure but it was
even worse than that because the
developers who submitted that code
strongly believe that that code itself
was secure so it may not matter that you
might say to yourself i would never do
this the fact of the matter is that the
way that we build
cryptography tools and cryptography
libraries directly impacts the security
outcomes for our users or the developers
and also their end users as well
i think mark twain sort of said it best
where he said it ain't what you don't
know that gets you into trouble it's
what you know for sure that just ain't
so
um so you might be super confident about
this but it doesn't necessarily even
matter
um and the great news for us is that
there is this burgeoning field um in the
humanities it sort of lives at the
intersection actually of comp sci and
humanities called human factors and
secure software development um and
there's been this massive explosion of
research over the last sort of 10 15
years in particular but i've seen you
know in looking at all these papers i've
seen at least three uh doctoral
dissertations in the last six months uh
for people that are uh that are trying
to acquire their phd um in human factors
and secure software development so
there's a rich vein original resource
that we can tap into here to learn what
the problems actually are and how we can
not make those mistakes and only make
new mistakes
um so what we're really going to do is
we're going to look at the usability
traps in the cryptography libraries some
of which you may be familiar with others
you may not be uh and the sort of things
that you can do to help your users avoid
them
uh and before we begin just a a quick
note we are talking about cryptography
not crypto and cryptocurrency uh we
don't serve any of their kind here um
and we're talking specifically about
developers when we say the users of a
particular piece of software we're
talking about those being developers uh
not the actual end users who may be you
know using uh using a high level
application to be able to store uh their
data and perform a particular task
the last thing as well to note is that
we're looking at peer-reviewed research
much of it has been replicated as well
and i've got an extensive list of
sources at the end that you can go and
have a look at yourself if you want to
dig into the details
really thorough complicated interesting
work and if you've got some time you're
looking for some light reading on a
sunday afternoon um i highly recommend a
lot of the papers that we're going to be
talking about today
so i want to start with a base level
fact which probably makes a few of you
uncomfortable in fact you know i'm
probably not talking to the people that
are in the audience here today because
if you care about security you're
probably at this talk but on the whole
developers pretty clearly don't really
think about security at all
so there's this fantastic paper uh
published in 2014 called it's the
psychology stupid how heuristics explain
software vulnerabilities and how priming
can illuminate developer blind spots
this resources is led by daniela olivier
and
this is a really interesting experiment
we're going to sort of rapid fire
through a bunch of different papers here
today so in this particular experiment
what they did was that they showed
developers six different code examples
that contained vulnerabilities so the
typical sort of things that you're
probably familiar with like buffer
overflows tls setup cross-site scripting
ii time to check the time of use sql
injection and brute force exhaustion so
what they did was they showed these
insecure code examples
to to uh to participants in this
particular study who are developers and
so the developers in this particular
study were grouped into three different
cohorts so there was control there was a
priming cohort and there was an explicit
cohort and so in the control cohort they
were asked what is the user input to
this program and what happens when this
code executes
in the priming cohort they asked those
same two questions but then they layered
two additional questions on top of that
they said could a developer experience
unexpected results when they run such
code
and what could examples of these
unexpected results be and where do they
appear in the code
and then in this third cohort
where they were explicit they just said
straight up this code has a
vulnerability can you pinpoint the
problem
and the results of this were that the
developers who were who are primed about
their potentially being a security
problem here identified security
problems at almost twice the rate of
unprimed developers
so one of the things that they say in
this paper is that security is not
really part of the heuristic used by
developers in their daily programming
tasks and that's because developers on
the whole focus mostly on functionality
and performance can i get this code to
run to meet a particular business or
organizational objective and does it do
it relatively quickly those are the two
top two things that developers are
actually focused on when they're writing
code on a day-to-day basis
um and the mental model that we have
when it comes to
security education that we think that
developers should learn about security
so often that's taking time out of their
day to to go and learn that or maybe if
they're going through an education
institution that's part of the course
work that they are doing and so they
should just go and learn that and then
they should apply
what they learn when they need it
and the fundamental reality here is that
this is not actually how humans actually
think you know we're great at acquiring
a whole bunch of different knowledge
but there are very specific triggers
that are required for actually having us
apply that knowledge at any particular
point in time
so
they make this really strong
recommendation that uh software that
interfaces with the developers so that's
like ides text editors compilers static
analysis tools
that those tools prime developers on the
spot when they need it
while they are actually coding so when
they are cutting the code in their text
editor and then running it that's when
we should be providing feedback to users
about their code potentially being
insecure or actually telling them hey
it's actually quite insecure the way
that you're using this right now
so the tldr for this particular paper is
the devs don't really think about
security but priming significantly
increases the likelihood of discovering
security bugs
so another potentially uncomfortable
truth something that you may know but
you really wish you didn't know is that
stack overflow provides functional yet
insecure code examples
to developers
and so there's this fantastic piece of
research that was uh published in 2016
by uh jasmine a car michael
bucks and uh sasha fall uh called you
get where you're looking for the impact
of information sources on code security
and in fact this particular group of
researchers um there's a they sort of
have a nice sort of narrative thread
through throughout everything that we're
going to be talking today this this
particular group uh based over in
germany a bunch of educational
institutions over there have done some
pretty phenomenal work on the human
factors uh in secure software
development over the last sort of five
to five to ten years
and so in this particular experiment
that they constructed back in 2016
what they did was that they recruited
android developers
through github and a variety of other
sources
and they provided those uh those android
developers with a skeleton app
and they were also presented with four
tasks in a random order here so they
were it was a combination of secure
networking secure storage
inter-component communication and lease
permissions
and so the developers were time boxed to
20 to 30 minutes per task and then at
the end of that they were asked to fill
out an exit survey about how they how
they felt they performed and whether
their code was secure
and so the android devs that were that
were run through this process were split
into four separate groups
so the first group they could only refer
to
information on stack overflow
the second group could only refer to
information in the official
documentation the third group could only
look at books and the fourth group could
look at any of these information sources
and the books weren't hard copy they
were actually a digital copy of the book
so they could use the table of contents
they could use like the fine
functionality and their pdf viewer
but yeah so it wasn't wasn't entirely
stone age but it's a relatively
comparable sort of technological means
to be able to access this information
but that information itself what sources
they could use was significantly
restricted
and the results well the results sort of
fall into two separate buckets so
there's the functional results where
they're able to deliver code that was
functional and did what it was intended
to do
and the second part was what is the
overall security of of those particular
results so let's look at the functional
first and so in the functional they
found that stack overflow people who use
stack overflow
had a significantly higher success rate
in fact stack overflow and books funnily
enough had a significantly higher
success rate than people that were using
only the official documentation or the
people who are doing free choice
uh in fact it's so bad that the the devs
that were assigned to the official
document official documentation actually
performed the worst overall which is
sort of a bit of a damning indictment i
guess of a lot of official documentation
particularly when it comes to
cryptography
so that's on the functional side but the
security side of things
was really interesting so they found
that with the lease permissions with
about 87 success rate that was the
highest out of all of them everything
else is about the same about sort of 38
to 40 percent so for the secure
networking the inter component coms and
secure storage it was very very low
success rate
but the confidence was super high even
though they were actually not producing
something that was actually secure
so on the whole developers self-assess
their solutions to be secure when they
mostly were not
and what that means for us as developers
is that in this particular study android
developers who use stack overflow they
do get functional code quicker but are
more likely to produce insecure code
see with that for a second like that's
that's pretty wild when you think about
it
and when we think about you know the
previous study we talked about a moment
ago
where you know we look at priming and
heuristics and whatnot
developers are mostly focusing on
functionality and performance so of
course they are going to continue to go
to stack overflow because it produces
functional code it helps them actually
meet their objectives the things that
they are often incentivized on within
their organizations mostly functionality
and performance
so they have a pretty strong
recommendation that it's really critical
for people who build cryptographic
libraries particularly in the open
source space to develop documentation
and resources that combine the useful or
the usefulness of forums like stack
overflow so a sort of a q a
type situation or like a forum
but with the security awareness of books
or the official api documentation
so
one really interesting thing that you
can do if you're a maintainer of an open
source cryptographic tool
is that you regularly spend time looking
back at yourself on stack overflow
looking at the questions that your users
are asking on stack overflow about your
library or about your tool
use that as a way to identify gaps in
your documentation that are being filled
by stack overflow
and then fill those gaps in your own
official documentation
because we're going to talk about this
in a second actually with some of the
other research but um typically the uh
the official documentation
tends to have the most secure uh results
for for developers
and so last thing to do here is to post
links and follow our comments um on the
accepted stack overflow answers back to
your official documentation and then
over time if you're looking at
your website analytics for your
documentation you should see an
increasing number of people going to
these pages and you should see your your
official documentation ranking higher in
google
so the tldr for this particular study is
that stack overflow answers they provide
functional insecure but yet insecure
code to developers and developers are
also really bad at assessing whether
that code is secure as well
quick side quest for a second though
there's this other paper that was
published only a couple of months ago
back in november of 2021
um about the effect of google search on
software security so
security interventions and doing content
re-ranking particularly for results
showing stack overflow and so i'll skip
over a lot of the detail of the study
but they basically found that there is
at least a 22.8 chance that one out of
the top three google search results for
stack overflow leads to insecure code
again that's another damning statistic
right there
so dldr your insecure code ends up in
the top results and is also clicked on
more often there's a higher engagement
with it so the study that they did for
this was really interesting so they used
like the google the google custom search
engine functionality to uh to boost or
unboost different bits of content and
they asked the uh
they asked the participants to perform
google searches using this custom search
engine that was built into the survey
tool um that that the users were going
or the developers were going through
during during this particular
this particular exercise
and they found that the participants
that used the modified search engine to
look for help online submitted more
secure and more functional results with
a significant statistical significance
so the gldr for that particular paper is
this is a fairly novel solution to the
problem that actually requires zero
behavioral change from developers
and my question is if there is anybody
that is listening to this talk today
that works at google can you please go
and i'll provide a link to this
particular paper at the end because i
don't know how much traction it's really
gotten outside of academic circles but
there i guarantee there is some product
manager uh or team within google that
could actually do something about this
and it would have an outsized effect
on the overall security of code that the
developers are shipping on a day-to-day
basis really really novel solution to
this problem and i would love to see it
implemented
particularly within google
all right so
the other um sort of hard to hear hard
to listen to truth is that most what we
call cryptography bugs actually come
from the use of the libraries not the
actual libraries
themselves
and so this particular study published
in 2014 uh called why does cryptographic
software fail a case study in open
problems um they they go into a whole
bunch of different areas in this paper
they cover sort of three or four
different topics and we're just going to
talk about one of them today which is
this
uh this particular part of the study so
what they did was they did an analysis
of uh 269 uh cves that there were
assessors having cryptographic ins uh
issues which is from the common weakness
enumeration from from mida and they
looked at that from january uh 2011 to
2014 and and that said this is the
foundational paper there are other
papers more recently that have
replicated this but you just sort of
articulated pretty clearly it was the
sort of first movers in this field
and what they did was that they
categorized the vulnerabilities uh for
for cryptographic issues um as along two
different dimensions one was impact so
uh whether it was a plain text
disclosure a manipulator in the middle a
brute force or a side channel attack and
then also at the layer as well so was it
at a low level cryptographic primitive
like aes or diffie-hellman was it the
protocol level so that could be some
sort of library or abstraction that
bundles up a bunch of cryptographic
primitives to be able to provide an
actual usable interface to the
developers that were needed to access
these primitives
and the last layer was the application
itself so you know issues particularly
like with plaintext disclosure outside
of the actual cryptographic libraries
themselves
um and the result of this was that 100
of plain text disclosures of information
86
manipulated are in the middle attacks
and 79 percent of brute force were in
the app layer now that said zero percent
of side channel happened at the the uh
the uh the primitive and protocol layer
um but that's the sort of problem that
you would expect to to be manifesting at
that layer right but a hundred percent
of plain text discloses were actually
happening in the
application layer and that mostly came
down to the way that the developers that
were using these libraries were actually
invoking them what the ergonomics of the
apis were that these libraries were
exposing
and so
what you can do as a cryptographic
library author or maintainer
is that you can try and expose
interfaces in your libraries that are
what the academic circles term as misuse
resistant and that's really what the
majority of the remainder of this talk
is going to focus on how do we actually
achieve misuse resistance and there's
heaps of research into this but there
are a fairly sparse actual directives as
to how to actually achieve this
so yeah what that fundamentally means is
that about 83 of all cryptographic bugs
come from the improper use of
cryptographic libraries not actually due
to cryptographic flaws inside those
libraries themselves which again another
pretty damning statistic
so
let's actually look at what you need to
do to improve the misuse resistance of
your libraries and the tools that you're
shipping to developers
and the tldr probably like the number
one thing that you can take away from
this talk today is that the features on
the periphery of your library and i'll
talk about what that means in a second
and the documentation that you ship with
your library are the absolute number one
requirement for developers to use your
library securely if you don't have an
extensive range of features an extensive
range of examples and recipes about how
to use it and extensive documentation
explaining all the different ways that
you can that you can use that library
you are doing a disservice to your users
and so this particular paper published
in 2017 like i i was originally just
going to do a talk exclusively about
this paper i can talk about this paper
hours it's it's it's a brilliant read um
it's super technical but it's also uh
it's very readable at the same time and
so this is by that same group of
researchers that i referred to
previously so yasmine car michael box
and sasha phil and simon garfinkel
and that's called comparing the
usability of cryptographic apis and this
has been cited heaps of times in the
last five years and i highly recommend
if you're going to read any paper out of
the stuff that i'm talking about today
go and have a read of this and i'll
provide some links at the end as well
so this particular experiment was really
interestingly constructed so what they
did was they recruited a bunch of python
developers and they assigned those
python developers five tasks with a
bunch of stub code so those tasks were
broken into two categories symmetric and
asymmetric so for symmetric it was key
generation and encryption and decryption
for the asymmetric it was key generation
encryption decryption and certificate
validation and at the end they also ask
the same sort of questions is the code
that you're actually producing here
secure
and they uh used a bunch of very common
well-known cryptography libraries that
you if you
a developer in the python ecosystem
you've chances are you've used one of
these libraries um so they were assigned
libraries uh that one of these five so
cryptography io kiza
pineapple uh sounds like pineapple
doesn't pineapple m2 crypto and pi
crypto and they were instructed
specifically to only use the included
docs from these different libraries now
you notice the the little sort of
asterisks that i've got listed there the
top three libraries that i that i
mentioned here are ones that make
explicit claims about the usability
focus for actually building those apis
and so trying to try to build a more
usable misuse resistance style
encryption
it's also probably if you're familiar
with the space as well it's worth noting
that key kizar was deprecated in favor
of tink by google in 2019 as well so
there's a whole bunch of things that
were fed into keys are but i actually
haven't seen this research replicated
with tink so if anybody is looking for a
little research project and you work in
an academic institution this would
definitely be one to take a look at with
tink
and the experiment that they constructed
was really interesting so what they did
was they modified a jupiter notebook
and include the stub code in here for
each of these uh for each of these tasks
that i mentioned in the previous slide
and one of the other things that they
did inside the jupyter notebook was that
they would uh regularly take snapshots
of the code and they also detected copy
and paste events as well to see where
people were actually copying code from
elsewhere on the internet so they could
trace it back to the original source
whether they were actually only getting
it from the official documentation like
they were asked to or whether they were
really actually going on to stack
overflow
and again the results are sort of in two
separate buckets here the functional
results and the secure results and not
to give too much of a spoiler but um
there's a similar discrepancy between
the previous research that we're looking
at and and this particular baby here
so the functional results found that
there was a wide variation of task
success across different libraries on
the whole asymmetric tasks were less
successful and they they offer some
discussion in the paper about why that
might be i think that the the general
sense of it is that uh asymmetric uh
encryption is just
generally less well understood
and thus people are more likely to make
mistakes with it but you know functional
solutions uh if you look at the
symmetric task for pineapple down there
um
very very high you know well i mean not
not perfect but greater than eighty
percent um so three out of the five had
uh had a functional solutions uh uh
fifty uh
greater than eighty percent of the tasks
had a functional solution lotus keys are
there though as we mentioned before it
was one of those uh libraries that made
explicit claims about the usability um
not good
like 40 of tasks less than 40 of tasks
had an actual functional solution
um and don't worry it gets even worse
when you actually look at the secure
results
but fun little anecdote from uh from the
jupiter notebook little thing that they
that they slipped in before they
actually found that copy paste code that
they were able to trace back to stack
overflow was three times more likely to
be functional on symmetric tasks so
developers love copy pasting
so if they're going to be copy pasting
code at least give them functional and
secure code to be copy pasting
uh the other interesting thing that they
found as well they did an overanalysis
of
of all the different results posted here
they found the python experience the
security background and the library
experience actually did not change the
success rate of
of of these particular functional tasks
so it doesn't really matter if you're a
super experienced python dev have got a
strong background in security or heaps
of library experience you perform
just as poorly as somebody that doesn't
have any of that experience at all which
is uh quite a humbling thing to hear
and then we get into the secure results
and it's an absolute bloodbath so in
this particular case although the
functional asymmetric tasks are very
very low uh they were three times more
likely to actually produce a secure
result uh keys are stands out amazingly
here you know you compare it to this one
right where you see the functional
results of keys are being very very low
but for the people that managed to do it
they had super secure results which is
um
curious not not good i would say
um so yeah that on the whole the
keysight usage was 25 times more likely
to be secure than any other library that
was used
but only 10 percent of the submitted
keys are solutions were actually
functional
which
yeah this is the sort of thing that i
cry into my pillow at night about it's
not good not good
um and as i mentioned at the at the top
of the talk twenty percent of the
submitted code was secure sorry insecure
but the developers strongly believed
that it actually was secure so a bit of
dunning-kruger going on here the less
you know about something the more
confident you are and the greater you
assess your competence at um compared to
people who do know something about it
which is uh yeah pretty sad
so what this actually means for us
though as tool authors and library
authors is that libraries with
simplified interfaces actually produce
more secure results
so misuse resistance is good for
security outcomes for our users and yet
security success rate was less than 80
even on the simplified libraries so not
great overall
um
one of the things that they found though
was that for the libraries that did
actually perform better on the uh on the
functional and security side of things
there was a lot more documentation and
code examples of peripheral features so
that's things like how do you do secure
key storage or how do you do
password-based key generation and those
peripheral features were actually the
things that would make or break the
security
or secure use of a particular library in
fact they found that the the call
signatures the way that these libraries
were being invoked
was generally secure but
the users the developers that were going
through these studies were actually copy
pasting
secure functional code but they didn't
have the uh the knowledge or the skill
to identify the danger because often in
those examples those code examples it
would have insecure inputs to these
libraries so you can't rely on a
developer identifying dangers
identifying sharp spots in your apis and
you definitely can't rely on them to
find secure alternatives as well so if
you you know if you your library uh
has this base level of features and
functionality but it requires
inputs
from other libraries uh or like things
in the core language you can't actually
rely on your users to actually use those
properly and know when to use them as
well
so what this fundamentally means for us
as library authors is that it is not
possible to have too many code examples
it is just like i cannot be clear about
this like
if you think that you have too many code
examples in your cryptography libraries
you don't you can just keep going in
fact you should keep going that will get
the best secure outcomes for your end
users or your developers in this
particular case
and it just reinforces the previous
findings as well that if devs can't find
working code examples in your
documentation they will go to stack
overflow and find a foot gun so
having great code examples
huge impact on the overall security of
delivered code by users
so the main thing that you can do here
as an author is create and maintain an
over abundance of secure code examples
in your libraries so like i said before
if you think that you have too many you
don't just keep going
the other thing that's really important
to do is to identify inputs and
dependencies that your users are
implicitly relying on so other language
features or other libraries that they
need to use to be able to use your
library appropriately and correctly and
securely and when you identify what
those things are either provide secure
wrappers for them
in your library so you know if you're
using a strongly typed language wrap
another type for instance with some
extra security
security checks around it right
and also document them exhaustively so
make sure that all of the code examples
that you have on your website are secure
doesn't even matter if you have a code
example that has a comment above it that
says this is insecure code and you
shouldn't use it developers will go and
click it they will just ignore the
comment and they will just copy the
insecure code and they will run it and
it will get a functional result but it
won't be secure so it's critical that
you have functional secure code examples
and you have an absolute plethora of
them
so the tldr from this particular paper
is that misuse resistance helps but it
ain't enough devs do crave code examples
and you need to provide them
all right as we wrap up with the
research here the last thing that that's
worth talking about is putting runtime
warnings into your api for potentially
insecure usage
so again another another paper from this
group
uh and with a bunch of other researchers
as well actually called developers
deserve security warnings too and it
talks about the effect of integrated
security on cryptographic api misuse and
this is published back in back in 2018
and so the experiment in in this
particular study was that they had the
python devs that were assigned three
tasks with the stop codes so the
symmetric key generation symmetric
encryption and key storage and they were
separated into two separate groups
whether they were using a control or a
patch version of pi crypto and again ask
the same question is your code actually
secure
and when we say a patched version of pi
crypto um they just did some pretty
basic uh
pretty basic sort of overloading of like
the constructor
so that when you would instantiate a
potentially insecure
cryptographic primitive that the library
was exposing it would print the standard
out and create
uh and it would make sure that it would
uh yeah that when it did create it that
you knew that you were doing something
potentially uh potentially unsafe
and the results of this are really
fascinating so they found that for the
control condition and the patch
condition the functional success was
about the same right but they found that
uh for the developers in the patch
condition that through these extra
warnings they basically they almost had
twice the level of producing a secure
a successful secure result as well as a
functional result
so nearly twice the rate and plus they
also self-assess their solutions as
being more secure when they were given a
warning as well
they also rated the control and the
patch versions uh equally usable there's
no negligible
statistical difference between their
ratings there
and so yeah the other really interesting
finding from this particular study was
that developers who wrote code that
triggered a warning were actually 15
times more likely to convert it to a
secure solution
so just that simple prompting like we
were talking about at the very beginning
of this talk that is enough to be able
to change the mindset and get developers
actually building
uh applications with your libraries in a
secure and functional way
and natalie studied this i'm not going
to go into the depth of this other paper
but there was a follow-up study to that
as well
that actually uh did like a
participatory design study for like what
those warnings were in those
cryptographic apis and the the tldr the
thing you need to focus on is that when
you provide uh errors or warnings
you want to provide a title message
color the source code location where
that particular problem was happening a
link to an external resource you don't
have to enumerate all the different
security problems just you know create a
link off to documentation on your site
saying hey if you get this particular
error this is the sort of thing that you
need to think about and the last bit is
message classification here
so those are really that's it like when
you create these runtime errors uh also
like having a way for people to be able
to suppress them as well is sort of
useful i'll talk about that in a second
actually
um
but just these five things alone if
you're able to surface those two
developers as they are writing code that
will uh significantly increase the
likelihood that they will deliver both
functional and secure code to their end
users by using your library
so the really fascinating thing from
this is that as a library author is that
you don't have to change your api shape
you have to change the ergonomics of
your api to actually increase the secure
usage of it so just emitting runtime
warnings does significantly improve
secure
secure usage of your library
without actually changing any of the
parameters what the interface is to your
library so if you can just look at what
is being passed or what is being
instantiated and you go oh we are
providing this particular insecure
function but there are like lots of foot
guns with doing this you should probably
not do that
that
does change the developer perception
about whether developing and delivering
secure code
and this tallies with that's what i
started with right it's the psychology
stupid so
that priming that is the number one way
to actually improve the secure usage of
your of your apis and goes back to what
they recommended you know prime
developers on the spot when they need it
while they are coding so the two things
that you can do here as a library author
is make your library emit warnings when
you detect potentially insecure usage
and provide an obvious mechanism as well
to be able to silence warnings the
reason for that second part um and just
to be clear i said obvious not easy like
you might have to you know utter a
certain incantation to be able to as a
developer using one of these libraries
to do the insecure thing
but you want to provide an obvious way
to do it it doesn't have to be easy for
them
and often that's because there are
organizational factors that are outside
the control of the developers like they
have to use in the secure cipher suite
because
they are
interfacing with some other third-party
piece of software that they don't have
any control over so you know you want to
allow them to do the insecure thing but
they need to really work hard to be able
to do that
so dldr use the runtime warnings to
prime developers about insecure usage
during dev
so
the takeaways for the talk today
developers don't really prioritize
security they focus on performance and
functionality none of that order they
focus on functionality and performance
and really as a cryptographic api uh
publisher author maintainer
you have to do a lot of the hard work
for them upfront to be able to get them
to produce code that is both functional
and secure
you can help developers or and people
that are using your libraries by
uh
prioritize security by providing
targeted warnings in your apis
frictionless misuse resistant apis that
work and are secure and copious secure
code examples in your documentation
can't emphasize that enough like just
keep going with the secure examples in
your documentation
most security bugs actually happen on
the periphery of your crypto
cryptography library it's inside your
users applications there's a whole bunch
of other really interesting research
into that which i'll link to in a moment
but it's all about doing the hard work
to make it easy for your users to be
able to use your library to be able to
get a functional
secure result
i'm lindsey holmwood thank you very much
for listening and i'm really keen to
hear what questions you have
okay there
thank you lindsay
so
we
just looking i don't see any questions
there at the moment
give people a little bit of time in fact
while people are thinking about the sort
of things that they're going to ask i've
got a heap of other documentation and
references to point you at so i've i've
got the slides published over here at
cifstash.com
lindsay if you're interested in the sort
of stuff that we're doing definitely
come help us we we're trying to build
next generation cryptography um but the
references are over here so this is all
the apa citations i've got links as well
to uh to all of these all these papers
in free and open access you don't need
to sign up for anything
the other thing as well
this is additional reading in case
you're super inspired by the talk you
want to go learn more about it
there's this paper from 2011 as well
that's really fantastic it's an
empirical study of vulnerabilities in
cryptographic libraries it builds upon
that 2013 research that i covered at the
very beginning of the talk
but yeah there's a huge amount of really
interesting research on this and if
you're passionate about it i highly
recommend you go and read it
okay thank you
so with that i think we can close a
little a few minutes early
and
oh no of hearing there is one question
okay so what are some examples of the
common mistakes made by developers in
the use of the apis
yeah that's a great question um so if
you're interested in about in learning
about that
um it's these two papers that you want
to check out so api blind spots this one
this original study was done with java
the second study replicated with python
and java
so often it's
down to passing insecure inputs
mostly copied from code examples
and what they were able to do in these
particular studies was that they
actually enumerate a whole bunch of
different common um insecure usages of
these different libraries it mostly
comes down to the inputs though that the
developers are passing what those li to
those libraries so yeah highly recommend
you go check that out
okay we have a another one
uh the tldrs are really useful how would
you
evaluate docs uh sufficient and
and you are not
getting any more benefits
that's a really good question um because
you know at the end of the day all
organizations have to economize like we
would love to be able to sit and write
documentation and code examples for the
rest of our lives um but there is
obviously a point of diminishing returns
um my strong recommendation for that is
actually usability testing with your
users ideally you could partner up with
an academic institution but you know if
you've got some sort of product function
if you're in a commercial organization
or you've got maintainers that have got
that sort of responsibility i highly
recommend constructing tasks like the
sort of things that were outlines in
these papers to actually look at how
people are using it um you you're using
your using your libraries as well as the
documentation that you are that you are
providing um i strongly recommend just
doing the qualitative and quantitative
research um
uh the other thing as well that you can
do is check out like look at how
particularly if you're on the open
source space look at like the github
code search how people are actually
using it there um being able to you know
reach out to the developers that
originally wrote that code and find out
how exactly they came to that point
um you know at the end of the day
i
every organization is going to have to
make a choice about where they economize
and what that point of diminishing
returns is um but you know have a think
about that ahead of time rather than
just doing a like it has to be a the
other thing as well has to be a constant
like repetitive
maintainable pace and process like as
you ship new features
and provide new functionality to your
users um you're going to have to
maintain all of the code examples that
you've got so it's it's also
that classic thing of like you know
having so many tests that eventually
like the crushing weight of the test
actually stops you from being able to do
delivery so it's this interesting
balance that you've got to find so
perhaps some of the heuristics that you
might use to work out you know what's an
optimal amount of test coverage that
probably applies to what we're doing
here with like code code examples for
your libraries
okay and maybe the final one because we
are on at 16 30 now
any advice on how to improve apis when
you need to also maintain compatibility
yeah that's a really great question um
i will be out front and say uh i don't
have any good answers for that um
i think that providing uh
sort of using some of the earlier
techniques that i talked about
actually the techniques towards the end
about providing warnings and things like
that
a really important way to be able to do
that
i would also argue that
it's okay to break backwards
incompatibility at certain points as
well but if you do that it is vitally
important that you create
smooth upgrade paths to the newer
version of whatever you're producing um
so google did that relatively
successfully with keys are and tink
they've got to a point where they
actually got a whole bunch of the
feedback from these particular studies
and went oh no
we really need to improve the usability
here so they actually just end of life
keys are entirely uh i probably use that
as an example about how to how to sort
of you know
encourage users to upgrade to the latest
greatest most secure most functional
thing
okay another question has popped up
let's see if we can squeeze that one in
to what extent can static types help
ensure
secure api usage uh that is great any
papers that look at this aspect of api
design
yes i don't have that linked in here but
i'll find you in the chat after this um
there is lots of research into that and
a lot of it is contradictory
so
yeah static analysis good but i'll link
you to the other stuff perfectly
take all that on the post talk chat
and uh definitely lindsay have a look at
the comments it was quite active while
you were talking
thank you very much