AWS re:Inforce 2022 - Cryptography for everyone with AWS libcrypto (DPP307)

Aug 16, 2023

AWS re:Inforce 2022 - Cryptography for everyone with AWS libcrypto (DPP307)

Join this session to learn about AWS libcrypto (AWS-LC) and why AWS is invested in improving open-source cryptography. Explore some of the challenges AWS faced migrating critical workloads to AWS-LC and how we’re helping our customers improve the performance and security of their applications.

Learn more about AWS re:Inforce at https://bit.ly/3baitIT.

Subscribe:
More AWS videos http://bit.ly/2O3zS75
More AWS events videos http://bit.ly/316g9t4

ABOUT AWS
Amazon Web Services (AWS) hosts events, both online and in-person, bringing the cloud computing community together to connect, collaborate, and learn from AWS experts.

AWS is the world’s most comprehensive and broadly adopted cloud platform, offering over 200 fully featured services from data centers globally. Millions of customers—including the fastest-growing startups, largest enterprises, and leading government agencies—are using AWS to lower costs, become more agile, and innovate faster.

#reInforce2022 #CloudSecurity #AWS #AmazonWebServices #CloudComputing

Content

0.21 -> - Hello, re:Inforce.

1.74 -> I'm excited to get started.

3.48 -> My name's Andrew Hopkins.

5.88 -> I'm a senior software development engineer

8.07 -> working on AWS's open source

9.78 -> cryptographic libraries and tools.

12.69 -> Today, I'm excited to introduce AWS-LC,

16.86 -> briefly reintroduce s2n-tls

19.14 -> for anyone not familiar with it,

20.82 -> and discuss how we migrated s2n-tls to use AWS-LC.

25.8 -> Along the way,

26.633 -> I'm gonna cover what we improved in AWS-LC

29.76 -> and how you can get started using it yourself.

33.87 -> Quickly, show of hands.

35.28 -> Who here is familiar with using libcrypto

38.03 -> or is familiar with cryptographic toolkits?

42.18 -> Oh, seems like maybe a little bit less than half.

44.49 -> Don't worry.

45.323 -> I'll get everyone up to speed pretty quickly.

47.43 -> I'm sure everyone here is very familiar

50.13 -> with using AWS services.

52.44 -> You might be familiar with like CloudFront, Amazon S3.

55.89 -> These services are available over the internet

58.53 -> and what they have in common with other tools

61.89 -> such as the AWS-SDKs is they need a mechanism

65.37 -> to communicate over the internet

67.38 -> and they need a mechanism to do so

69.27 -> with privacy and security in mind.

72.06 -> The way these higher-level services

74.01 -> and applications accomplish this

75.99 -> is by using some network security protocols.

79.14 -> Everyone here has probably used TLS,

81.54 -> the Transport Layer Security.

83.61 -> This is how you probably are most familiar

85.74 -> with connecting to AWS services.

88.35 -> TLS is a protocol.

89.85 -> It defines the message format and handles the negotiation

93.9 -> of which algorithms and keys

95.88 -> are used to secure your communication

98.07 -> when connecting to AWS.

100.41 -> Another protocol you might be familiar with is SSH.

103.38 -> This is how you'll be connecting

104.61 -> to your Linux-based EC2 instances,

107.31 -> and like TLS,

108.27 -> it defines the message format

110.64 -> and handles the negotiation of algorithms.

113.16 -> But critically, these networking security protocols

116.16 -> don't actually implement any of the algorithms.

119.07 -> They rely on another dependency

121.17 -> to actually provide those implementations,

123.48 -> and that's where cryptographic toolkits come into play.

127.717 -> Cryptographic toolkits will provide both the algorithms

130.98 -> and some of the utility functions

132.48 -> you might need in your higher-level

134.37 -> protocols and applications.

136.23 -> You might be familiar

137.07 -> with X.509 certificate parsing and validation.

140.55 -> This is how AWS services authenticate themselves to you

144.33 -> as the customer to make sure you're connecting

146.28 -> to the real AWS services.

149.64 -> Inside these toolkits,

150.57 -> you'll also find the algorithm implementations.

153.48 -> I'll be talking a lot in this talk

154.92 -> about elliptic curve Diffie-Hellman.

156.93 -> This is commonly used in TLS and SSH

160.59 -> to establish secure keys between the clients and servers.

165.15 -> Another algorithm you'll hear me

166.8 -> talk a lot about today is ASGCM.

169.26 -> This uses the secure keys from elliptic curve Diffie-Hellman

172.8 -> to secure your data in transit to AWS.

177.66 -> Every cryptographic toolkit will also possibly

180.51 -> provide optimizations that depend on specific processors.

184.83 -> This is where you have hardware instructions

187.32 -> to do crypto faster,

188.82 -> and this is the lowest layer here

190.62 -> that's kind of processor specific.

193.41 -> Every cryptographic toolkit will have a choice of

196.02 -> which algorithms to provide and which APIs to provide,

199.53 -> and for AWS-LC, we made a particular choice.

202.89 -> I won't cover too much of

204.78 -> all of the algorithms or functions we have.

207.63 -> For that, I'll refer you to our open source documentation

211.08 -> and public header files.

213.63 -> But what's important for AWS-LC

215.55 -> is we chose our particular API trying to target

219.51 -> the most important functions

221.34 -> and algorithms for AWS and our customers,

224.49 -> and another key component of AWS-LC is the FIPS Module.

229.38 -> Don't worry, I'll cover more about what is FIPS later on,

232.56 -> but for now, we'll just remember that

234.45 -> we validated a subset of AWS-LC,

237.42 -> and that is the FIPS module.

242.85 -> Every team at Amazon has tenets,

245.25 -> and AWS-LC's team is no different.

248.31 -> First and foremost is correctness and security.

251.1 -> We designed and implemented AWS-LC with correctness in mind.

254.88 -> This is ensuring we get the correct and expected answer

258.21 -> for all the algorithms you are using,

260.4 -> but it's not just sufficient to be correct.

262.32 -> We also must be secure.

264.03 -> This is secure from potential side-channel attacks

266.85 -> where you reveal sensitive information,

269.46 -> and also from memory corruption,

271.44 -> where maybe we reveal information and memory

273.72 -> that you don't expect.

275.31 -> We use a variety of tools and tests

277.86 -> to ensure AWS-LC is both correct and secure.

282.75 -> Next most important for us

284.01 -> is maintaining backward-compatibility.

286.32 -> We realize AWS-LC is constantly in motion.

289.47 -> We're developing new performance enhancements,

292.08 -> new security features,

293.67 -> and for our customers and AWS teams

296.13 -> to easily adopt those new features,

298.29 -> we must make it easy for them to stay up to date.

301.11 -> And we do that by maintaining backward compatibility

303.78 -> such that we're not breaking customers

306.09 -> or other dependencies every build.

308.97 -> And like I mentioned, performance is key for Amazon.

312.33 -> We are super focused on performance as well for AWS-LC,

316.08 -> but critically,

316.95 -> it's not performance at the cost of security,

319.44 -> and we're trying to not hurt security

322.23 -> in the aims of performance.

323.52 -> We're aiming to provide both high-quality,

326.22 -> secure implementations and high-performance implementations.

331.56 -> For some certain workloads,

333.57 -> compliance plays a key part with cryptography.

336.33 -> This is where FIPS 140 is an example of this,

339.63 -> and we want to make sure it's easy for customers

341.82 -> who need to meet certain compliance

344.46 -> are able to do so by using AWS-LC,

347.91 -> and we want to make sure customers that need that compliance

350.67 -> can continue to get a good experience

352.77 -> so we're continuously re-validating AWS-LC

356.22 -> to make sure you can always use

358.62 -> the latest features and enhancements.

361.56 -> Finally, AWS-LC is developed open-source on GitHub.

365.76 -> We believe it's important for us to be transparent,

368.49 -> and this also helps it be easier for our customers

371.61 -> to interact with us and for us to interact

373.38 -> with the broader open source cryptographic community.

376.17 -> And by being open source,

377.49 -> we're able to contribute back some of

379.59 -> the valuable lessons learned and improvements we've made.

385.77 -> For anyone not familiar with s2n,

388.95 -> it is a family of open-source

390.81 -> cryptographic protocol libraries

392.88 -> focused on encryption in transit.

395.7 -> The two key libraries that we'll be talking about

398.07 -> are s2n-tls and s2n-quic.

400.95 -> For anyone who might have seen my coworker's presentation,

403.68 -> NIS 304 using s2n-quic,

406.38 -> they went into more details about the advantages of QUIC,

409.77 -> but for this talk, we'll be focusing on s2n-tls,

413.19 -> which like the name suggests,

414.81 -> is a library that implements the TLS protocol,

419.07 -> and if you remember from the previous slide,

422.194 -> s2n-tls and s2n-quic are protocol libraries

425.22 -> and they need another library

426.93 -> to actually provide those algorithm implementations.

430.11 -> Currently, s2n-tls supports multiple cryptographic toolkits.

435.45 -> We do this to to make it easy to use

438.75 -> what is available to you in your environment,

441 -> and this talk is all about the work we did

444.18 -> to add support and migrate s2n-tls to AWS-LC's toolkit.

451.68 -> For a timeline of the events,

453.777 -> s2n-tls launched in 2015

457.8 -> and quickly gained internal adoption,

459.99 -> and by 2017 was serving

462.21 -> all of Amazon S3's front-end web traffic to customers.

467.73 -> After we hit that milestone,

469.44 -> we began looking at post-quantum cryptography,

472.41 -> and in 2019,

473.4 -> we added support for hybrid post-quantum key exchanges.

477.51 -> We did this with three AWS services

481.38 -> to let customers begin experimenting

483.54 -> with post-quantum cryptography in AWS,

487.44 -> and these hybrid cipher suites

489.36 -> maintain the high security and confidence

492.39 -> from the past algorithms

493.92 -> with the expected post-quantum security

496.77 -> of the new algorithms.

498.48 -> This is particularly exciting because NIST just announced

501.9 -> the final selections for some of

503.49 -> the post-quantum cipher suites or ciphers.

508.74 -> With the advancements we were seeing

512.46 -> by taking greater control

514.47 -> of s2n-tls's algorithm implementations in cryptography,

518.85 -> we began investing in our own cryptographic toolkit,

521.85 -> and in 2019, we launched AWS-LC

524.82 -> with the AWS Nitro Enclaves SDK for C.

529.38 -> And shortly after launching,

530.49 -> we began the work to migrate s2n-tls to AWS-LC,

535.62 -> and along this whole way,

537.75 -> we've been working on x86

539.49 -> and ARM optimizations in AWS-LC,

542.67 -> particularly looking at newer graviton instances

545.67 -> and taking as maximum advantage

547.8 -> of the new performance they offer.

550.38 -> And in December of 2021,

552.84 -> we submitted AWS-LC for FIPS 140-3 validation, and, again,

557.61 -> I'll cover more about why that

559.29 -> might be important to your use case later.

563.85 -> So, what was actually involved in that migration

566.85 -> of s2n-tls to AWS-LC?

569.37 -> We identified four key checkpoints.

572.73 -> First was coexisting with other dependencies.

575.97 -> We knew from the start,

576.96 -> we only wanted to migrate the TLS layer to using AWS-LC

580.5 -> and we wanted to leave the rest of higher-level applications

583.95 -> available to use whatever toolkits they wanted to use.

586.95 -> This was important for us

587.837 -> 'cause it minimized the blast radius

590.4 -> by minimizing the change.

592.14 -> We were only changing the TLS layer.

595.86 -> Next was making sure AWS-LC provided the same APIs

600.03 -> that s2n-tls needed and that those APIs

602.85 -> behaved the same that they expected them to.

608.04 -> Like I said, a theme of AWS-LC is performance,

610.62 -> and we wanted to make sure by migrating to AWS-LC

613.38 -> we didn't negatively impact

615.03 -> any of s2n-tls's customers' performance.

618.36 -> And finally,

619.65 -> a key part of all of this was meeting

621.39 -> the same regulatory requirements that s2n-tls needed.

627.69 -> So, the first step for the migration

631.02 -> was making sure AWS-LC

632.67 -> could coexist with other dependencies,

634.83 -> and to kind of understand the problem,

637.44 -> we'll go to quickly explain linking,

640.2 -> and in this case, linking on Linux operating systems.

644.25 -> Here, we have two applications and two libraries,

647.4 -> A and B, that each provide two functions, A and B,

651.66 -> and here, everything is okay

653.07 -> because the libraries are providing different functions,

656.46 -> so there's no conflicts,

657.6 -> and the application can use

658.83 -> both libraries together seamlessly.

662.851 -> This is a small problem for AWS-LC, though,

665.22 -> because we want to maintain some level

667.56 -> of cross-compatibility with existing toolkits.

670.47 -> So, what this means is AWS-LC

673.14 -> provides similar functions with similar names,

676.74 -> and in many cases,

677.573 -> the exact same names as other toolkits,

680.34 -> and with, at least, native libraries,

684.51 -> you're not allowed to have multiple functions

686.76 -> with the same names loaded at the same time.

689.28 -> This will result in a symbol conflict,

691.32 -> and depending on your tool chain and how you are using us,

695.13 -> this will result in a link-time error

697.17 -> or a runtime only one library getting loaded.

700.62 -> And this is a problem, again,

702.15 -> because we wanted to make it easy

704.01 -> for customers to move to AWS-LC

706.17 -> and minimize that blast radius

707.64 -> so it's only s2n-tls using us.

710.97 -> Our solution to this was introducing

714.15 -> a Prefix static build into s2n-tls.

718.02 -> Using this technique,

719.46 -> we're able to build AWS-LC and s2n-tls together

723.27 -> and then update all of the symbols

726.12 -> and the symbol references

727.47 -> in those two libraries to use a prefix

729.81 -> so they don't conflict with other libraries

732.42 -> in use on the system.

734.25 -> This is extra valuable for s2n-tls because they can then

738.3 -> bundle us inside their library as a static artifact

742.11 -> and be completely transparent to customers

745.05 -> about what cryptographic toolkit they're using.

747.84 -> And this lets s2n-tls

749.28 -> move their customers onto us seamlessly.

756.33 -> So, the next checkpoint for us

758.79 -> was ensuring API compatibility,

761.73 -> and the way we did that was through exhaustive testing.

765.51 -> We built our continuous integration

767.73 -> using AWS CodeBuild and AWS Device Farm.

771.21 -> CodeBuild enables us to run multiple test suites

774.72 -> all in parallel across multiple

776.91 -> operating systems and processors,

779.76 -> specifically x86 and ARM.

783 -> AWS Device Farm lets us do the same,

784.89 -> except testing on mobile operating systems

786.99 -> and mobile processors,

788.397 -> and this ensures no matter where you use AWS-LC,

791.79 -> you get the same quality assurances

794.43 -> and same compatibility that

795.93 -> will build successfully in your environment.

799.65 -> The first part I'd like to call out is unit tests.

802.17 -> Unit tests are great for testing algorithms

804.78 -> that have a standard.

806.01 -> These standards will define exactly

809.52 -> what the algorithm should do,

811.29 -> and in many cases, they will include known-answer tests,

814.65 -> such as for AES encryption,

816.6 -> given a particular key and plain text,

819.45 -> you will always encrypt and get this cipher text.

821.94 -> And AWS-LC uses this for all of

824.01 -> the algorithms that we support.

827.55 -> The next interesting part was fuzz tests.

831.03 -> Fuzz tests,

831.96 -> we use libFuzzer to generate random inputs

834.81 -> and pass them to AWS-LC to make sure

836.91 -> there's no undefined behavior,

838.89 -> but we actually went one step further

840.6 -> with differential fuzzing.

842.31 -> The differential part of this is we actually test AWS-LC

845.97 -> against multiple other cryptographic toolkits,

848.73 -> ensuring our library produces

850.98 -> the same output as the other toolkits

853.47 -> and that everyone agrees on the correct answer.

856.95 -> But just with unit tests and fuzz tests,

858.93 -> that's actually still not sufficient.

861.81 -> We build as a part of our build s2n-tls

864.9 -> and ensure their tests pass when built with us,

868.26 -> and this actually kind of found a fun,

870.06 -> interesting bug early on in development.

874.05 -> Like I said,

874.883 -> some algorithms have standards,

876.27 -> and those standards have known-answer tests,

878.61 -> but some functions in AWS-LC don't have a standard.

881.7 -> In one case, Base 16 or Hexadecimal encoding of data,

885.9 -> there's no standard or agreed-upon convention

888.42 -> whether you should use capital or lowercase A through F's,

891.9 -> and in this case,

892.733 -> AWS-LC actually differed from s2n-tls's expectation,

897.66 -> but, again, because we're

899.37 -> running s2n-tls's integration tests with AWS-LC,

903.72 -> we're able to catch that and fix it

905.58 -> and make sure everyone agrees

906.78 -> on the correct capitalization of Hexadecimal data.

912.12 -> The next interesting box I'd like to dive deeper into

915.66 -> is formal verification.

917.22 -> Formal verification can be used

920.22 -> to mathematically prove properties of a system,

922.89 -> and this is very valuable for AWS-LC

925.98 -> because it lets us prove exhaustively

928.08 -> that our algorithms are correct.

929.88 -> These known-answer tests that I talked about

932.13 -> in the unit tests only prove that we get the correct answer

935.67 -> for a certain subset of the inputs.

938.19 -> There's no guarantees that there

939.48 -> aren't other subtle edge cases

941.73 -> or conditions we don't handle.

943.71 -> Using formal verification,

945.54 -> we're able to prove exhaustively

947.4 -> that for all possible inputs,

949.35 -> AWS-LC is producing the correct output,

953.76 -> and this is valuable for s2n-tls

956.04 -> because they're used across many AWS services

959.19 -> handling a lot of data

961.17 -> and is very likely to possibly hit these edge cases that,

965.25 -> thankfully, formal verification can prove

967.47 -> that we're not going to hit.

969.99 -> For formal verification, we took two approaches.

973.77 -> First, we wanted to formally verify

976.35 -> our existing implementations.

979.23 -> One example of this is AES-GCM.

981.9 -> We have a highly optimized,

983.73 -> highly performant version of as AES-GCM

986.79 -> included in AWS-LC that is built using C code

990.24 -> to provide a nice customer API

992.73 -> and optimized machine assembly code for x86 and ARM.

998.52 -> We didn't want to necessarily have

1000.05 -> to change this implementation,

1001.73 -> but we still wanted the benefits of formal verification.

1004.64 -> That's why we created the AWS-LC verification repository,

1009.32 -> which includes formal verification proofs

1011.99 -> of some algorithms in AWS-LC.

1014.96 -> We built AWS-LC verification using Cryptol,

1018.95 -> which is a domain-specific language

1021.14 -> for specifying cryptographic algorithms.

1024.77 -> This lets you mathematically specify the algorithm once

1028.43 -> and then reuse that specification

1030.44 -> in multiple different areas.

1032.45 -> We did that using the Software Analysis Workbench.

1035.72 -> What the Software Analysis Workbench does

1038.39 -> is it proves equivalence that our C and x86 assembly code

1042.8 -> is equivalent to the mathematical specification

1045.367 -> of AES-GCM in this example.

1048.8 -> And this is powerful because it lets us

1050.87 -> change our AWS-LC code and prove that it is still correct

1055.58 -> because the mathematical specification

1057.8 -> in Cryptol did not change.

1060.02 -> That is written kind of once and it never has to change,

1063.53 -> whereas the code can be updated

1065.99 -> to take advantage of new improvements.

1070.28 -> For more information on this,

1071.93 -> you can see the AWS science paper

1074.307 -> "Verified Cryptographic Code for Everybody,"

1077.3 -> and I'm excited to talk about the fact

1079.52 -> that we contracted with Galois,

1081.71 -> the developers of

1083.18 -> the Software Analysis Workbench and Cryptol,

1085.52 -> to add additional functionality to their public tools

1088.46 -> that you can also take advantage of.

1090.62 -> They built two new tools to accomplish all of this,

1093.59 -> specifically being able to prove and reason

1096.68 -> about mixed C and x86 assembly at the same time,

1100.73 -> and the ability to prove unbounded results

1104.48 -> or results about unbounded input.

1108.68 -> Yes, using this technique,

1109.753 -> we were able to keep our fast, optimized implementation

1114.71 -> and get all of the high-quality assurances

1117.41 -> that formal verification provides.

1128.12 -> The next approach we used for formal verification

1132.35 -> was developing all new code in the proofs in parallel.

1137.78 -> And that's why we made s2n-bignum.

1140.78 -> For those who aren't familiar,

1142.31 -> a bignum library is useful in cryptography

1145.549 -> to do mathematical operations in numbers

1149.57 -> that are larger than what a CPU can traditionally handle.

1152.48 -> This is convenient and required for some cryptography,

1155.87 -> such as elliptic curve Diffie-Hellman

1157.7 -> with 500-bit numbers that don't fit

1160.19 -> in a traditional CPU register.

1163.37 -> We knew early on that we wanted

1165.23 -> to improve our elliptic curve performance

1168.53 -> because most TLS handshakes

1173.48 -> use elliptic curve Diffie-Hellman,

1175.19 -> and it is a key performance

1178.1 -> for improving the overall handshake latency.

1181.28 -> So, we began by writing

1184.7 -> optimized assembly code for x86 and ARM,

1187.91 -> and in parallel with that development,

1190.31 -> building the proofs that proved the assembly was equivalent

1193.97 -> to the mathematical operation.

1196.34 -> You can think of two 500-bit numbers added together

1199.22 -> will always produce the correct result.

1203 -> And once we had s2n-bignum fully written and verified,

1207.23 -> we were able to integrate that code

1209.03 -> into AWS-LC's elliptic curve functions,

1213.02 -> and s2n-bignum is also available

1215.15 -> as a standalone open-source library for those of you

1217.85 -> that also are working on cryptographic toolkits.

1224.03 -> So, this kind of is a nice segue to performance.

1228.38 -> So, we built s2n-bignum both for the performance benefits

1231.77 -> of a highly-optimized implementation of bignum libraries,

1237.71 -> but we also wanted to look at our other performance,

1240.5 -> and we took a tiered approach to this performance testing.

1243.59 -> Starting with the bottom layer, AWS-LC,

1246.26 -> we looked at the cryptographic algorithms in isolation.

1249.86 -> This is our performance of our code

1252.47 -> tested using our speed tool

1254.27 -> that's available for you to also run in our repository.

1259.19 -> Looking at this,

1260.023 -> we were able to compare the different parameters

1262.79 -> and algorithms on different platforms

1265.43 -> and see how the performance compared

1267.05 -> and where we wanted to improve things,

1269.39 -> but that's not the complete picture.

1271.52 -> This doesn't really show the relative importance

1274.46 -> of some of those algorithms

1276.08 -> or how they get used in real applications.

1278.51 -> For that, we benchmarked s2n-tls.

1282.47 -> At the s2n-tls layer, we're looking at handshakes.

1286.13 -> This is what customers actually do

1288.11 -> when they're connecting to AWS for the first time.

1290.63 -> They're establishing those shared keys,

1292.88 -> and that is one of the key performances impact

1297.5 -> for first-time connections,

1300.08 -> but that's not necessarily the most important

1302.03 -> for all connections.

1303.71 -> For some AWS services,

1304.94 -> you might be transferring large amounts of data and a small,

1308.81 -> little TLS handshake is a insignificant

1311.39 -> amount of that performance.

1312.8 -> So, for that, we looked at the data encryption.

1315.5 -> This is the actual bulk encryption

1317.78 -> of the messages you're sending back and forth to AWS,

1322.52 -> and this is where benchmarking AES-GCM was important.

1327.98 -> But still, this is not the complete picture.

1331.07 -> For the complete picture,

1332 -> we had to look even one level higher with applications.

1336.32 -> At the application layer,

1337.43 -> we're actually looking at what is the customer impact

1340.52 -> of this migration to their overall request flow.

1344.15 -> Very few customers are probably thinking about TLS,

1347.09 -> but they're thinking about their DynamoDB GetItem requests

1351.08 -> and the performance of that first time

1353.21 -> you're connecting to a new service,

1355.01 -> and this is where customer request measuring is important.

1358.97 -> We looked at latency for our customers and CPU utilization

1363.92 -> for the AWS services that we're deploying AWS-LC,

1368.6 -> and with this, we were able to identify

1372.11 -> and improve the algorithms.

1373.97 -> This is why, like I said,

1375.53 -> we invested in s2n-bignum,

1378.02 -> and we also invested in some other algorithms

1380.36 -> that were most important for AWS and our customers,

1385.19 -> and I'm excited to share

1386.57 -> some of the performance results with you.

1388.67 -> So, this table is showing AWS-LC's pure performance

1393.74 -> tested on an EC2 C7g instance.

1397.91 -> This is kind of that bottom layer of performance

1400.16 -> I talked about on the previous slide,

1402.05 -> and is showing our performance on the same instance

1404.93 -> with our code from 2020 and today in 2022.

1409.97 -> I should call out that we were very happy

1411.62 -> with our performance initially in 2020.

1414.2 -> We were matching the industry performance

1417.05 -> for these algorithms,

1418.34 -> but we knew with the increased adoption

1420.92 -> of graviton and ARM processors

1423.38 -> that we wanted to invest in further improving

1425.9 -> that performance for ourselves in AWS

1428.477 -> and for our customers running their workloads on ARM.

1433.13 -> So, this table shows elliptic curve Diffie-Hellman

1436.34 -> with three different parameters.

1438.71 -> These different parameters provide

1440.63 -> different levels of security.

1442.55 -> P-256 is one of the most common ones

1444.68 -> because it provides an adequate level of security

1447.71 -> and is the most performant,

1449.36 -> and is the most widely used ECDH variant.

1454.1 -> But what I'd like to highlight is P-521.

1457.61 -> For a reference point,

1458.78 -> a standard TLS handshake within one AWS availability zone

1463.01 -> is going to be on the order

1464.12 -> of magnitude of a few milliseconds,

1466.73 -> so most customers didn't want to use P-521

1470.33 -> because the performance impact

1471.68 -> of migrating to that higher-level security

1474.53 -> meant that they would be effectively

1475.82 -> almost doubling their TLS handshake time.

1478.85 -> But through the use of s2n-bignum and other improvements,

1482.15 -> we were able to get that latency down

1484.43 -> to almost half a millisecond,

1486.23 -> and at this level,

1487.063 -> it is no longer prohibitive to use P-521 for applications

1491.3 -> and you can take advantage

1492.38 -> of the higher-level security provided by P-521.

1497.42 -> I also included two symmetric ciphers:

1500.63 -> AES-GCM and ChaCha Poly.

1502.88 -> These are used for the bulk encryption

1505.46 -> between AWS and clients.

1507.65 -> Here, it's measured in megabytes per second,

1510.5 -> and higher values are better,

1512.36 -> and you can see we were also able

1513.89 -> to improve the performance of both of these,

1516.47 -> and AES-GCM is highly used

1520.07 -> because it's been highly optimized,

1521.6 -> and there's lots of hardware support

1523.46 -> already in use in modern processors,

1525.98 -> and ChaCha Poly is widely used

1528.29 -> because it's efficient for low-powered devices,

1531.02 -> such as phones, to implement in software.

1534.89 -> Oh, and I should quickly call out

1536.45 -> the ECDH numbers are measured in milliseconds.

1539 -> So, that is the time for one operation, and lower is better.

1544.88 -> So, we accomplished all of this

1546.47 -> through a combination of algorithm improvements

1549.29 -> and taking better advantage

1551.66 -> of those hardware capabilities to us.

1555.32 -> And what's really exciting is we're able

1557.27 -> to share some of these performance improvements

1559.85 -> with the broader cryptographic toolkit community.

1562.34 -> So, we took the lessons we learned

1564.77 -> from developing these performance improvements

1567.11 -> and contributed to them back to other open source libraries.

1570.53 -> We did this because we knew it was important

1572.75 -> for our customers to have the fastest-possible crypto,

1576.35 -> but not all of our customers

1577.46 -> are going to be able to use AWS-LC on Day One,

1580.64 -> but they still deserve to have

1581.87 -> the best performance and cryptography available

1584.99 -> with whatever application and toolkit they're using,

1587.72 -> so we're able to contribute some of these changes back

1590.24 -> and we're going to continue

1591.53 -> to contribute future changes when possible.

1597.2 -> The next checkpoint for the s2n-tls migration was FIPS.

1603.41 -> Who here is familiar with FIPS 140?

1606.53 -> Ah, way more people.

1607.82 -> Exciting.

1609.17 -> Great.

1610.003 -> So, you're probably all familiar with the fact

1611.81 -> that we're kind of in this transitionary period.

1614.39 -> We used to have FIPS 140-2.

1616.55 -> It was published in 2001,

1619.13 -> and now we're moving to FIPS 140-3,

1621.56 -> the new standard for cryptographic modules from NIST.

1626.15 -> And in this transitionary period,

1628.7 -> NIST added some new requirements to the FIPS 140 standard,

1633.02 -> and have also kind of tweaked some of the algorithms

1635.18 -> available in the new standard.

1637.55 -> And AWS-LC had two main development points

1641.12 -> that we had to tackle in our submission process for FIPS.

1647.9 -> The first is randomness.

1649.79 -> So, randomness is very important for cryptography.

1652.67 -> This is what ensures when you generate your keys

1656.09 -> that you're generating secure keys

1658.43 -> that aren't able to be predicted or guessed by an adversary.

1663.2 -> Randomness also comes into play

1665.17 -> in TLS that uses random nonces

1667.82 -> and other random values that can't be predictable.

1671.72 -> So, traditionally, cryptographic toolkits

1674.27 -> have used hardware sources of randomness.

1678.53 -> You might be familiar with RDRand on x86 processors.

1683.33 -> This is an instruction that

1684.77 -> calls special hardware on your processor

1687.92 -> that returns random values.

1690.14 -> This is super valuable for toolkits

1692.18 -> because this is very fast,

1693.71 -> and it's very efficient to use RDRand.

1696.29 -> However, new in 140-3

1699.14 -> is the requirement that cryptographic modules have to meet

1702.38 -> the NIST Special Publication 800-90B requirements,

1706.61 -> and this is the requirement

1707.99 -> for secure randomness generation,

1710.87 -> and what this basically does is

1712.85 -> it moves the source of randomness

1715.07 -> into review for the module,

1718.58 -> and this is tricky for AWS-LC

1720.11 -> because we're a software library.

1722.09 -> If you're developing, say, like a hardware security module,

1725.63 -> you're going to have one processor

1727.37 -> and one version of code that you're targeting

1729.56 -> and you can go through the review process

1731.93 -> to make sure that your source of randomness

1734.39 -> meets this requirement,

1735.83 -> but AWS-LC is going to be run on a variety of platforms

1739.85 -> and we don't necessarily have the capability

1742.61 -> to review with NIST and our FIPS lab all of those platforms,

1747.71 -> so we needed another solution

1749.54 -> to meet the 800-90B requirement.

1753.29 -> And for this, we used the technique called CPU Jitter.

1757.607 -> CPU Jitter provides a method in software

1761.78 -> to produce secure, high-quality randomness

1766.34 -> without requiring any specialty hardware on your processor.

1771.08 -> All it needs is the very common instructions

1774.98 -> to get accurate timing

1776.81 -> and doesn't necessarily require

1778.58 -> specialty RDRand instructions.

1782.96 -> So, using CPU Jitter is valuable for us

1787.28 -> because they've already been shown

1789.44 -> to meet the requirements of 800-90B.

1792.44 -> So, we were able to take CPU jitter,

1795.47 -> which is both a process for generating randomness

1799.4 -> and is also the name of a library

1801.2 -> that implements that process,

1803.45 -> and integrate it into AWS-LC's

1805.61 -> secure key generation algorithm.

1809.72 -> But our key generation algorithm

1811.46 -> also lets us mix in additional randomness,

1814.64 -> which we're still doing using

1816.26 -> the traditional hardware random number generators,

1818.66 -> because those are, like I said,

1820.19 -> very high-performance, very cheap, and easy to use.

1823.94 -> So, we get kind of the best of both worlds,

1825.89 -> the FIPS security from CPU Jitter

1828.59 -> and the performance of the hardware random number generator.

1836.21 -> The next requirement that was new for 140-3

1839.63 -> was the requirement to add a approved service indicator.

1844.49 -> So, if you look back at FIPS 140-2,

1847.73 -> you might be familiar with reviewing security policies.

1850.61 -> These are documents that outline

1853.46 -> what a cryptographic module has been approved to do,

1857.09 -> and it outlines the algorithms and APIs that are approved.

1861.32 -> New in 140-3 is the service indicator.

1864.59 -> This is a runtime method of providing similar information.

1869.93 -> This requires AWS-LC to have new public APIs that you,

1875.12 -> as our customers,

1875.953 -> can call to see if you're using

1877.487 -> AWS-LC in an approved manner,

1880.04 -> and this is valuable because we provide both approved

1883.46 -> and non-approved algorithms at the same time.

1886.01 -> This is useful because there are many use cases

1888.47 -> that don't need FIPS-approved crypto

1891.23 -> for some of the utility functions,

1893 -> and it's convenient for you to continue

1895.22 -> to use those from AWS-LC,

1897.92 -> and using the service indicator,

1899.57 -> you can now easily check that you're

1901.49 -> doing the correct thing that you expect.

1906.2 -> And as the service indicator

1908.21 -> is a new requirement from 140-3

1912.98 -> and we were a new library

1914.24 -> going through the submission process,

1916.07 -> we were one of the first to implement

1918.23 -> a approved service indicator.

1920.03 -> And, again, we were able to share that implementation

1922.55 -> with other open-source cryptographic toolkits,

1926.21 -> just saving everyone time and helping to standardize

1929.57 -> on the API that is used for the indicator.

1934.61 -> So, with all of this,

1937.22 -> we were able to finish

1938.48 -> the regulatory requirements for s2n-tls, and with that,

1942.8 -> fully unblocks the s2n-tls migration to AWS-LC.

1949.52 -> So, we had accomplished making sure

1951.59 -> we were compatible with other dependencies,

1954.17 -> we ensured we were API-compatible with the cryptography

1957.83 -> that s2n-tls needed,

1959.87 -> we ensured we met the same performance requirements

1962.12 -> and regulatory requirements,

1964.22 -> but that's just the beginning.

1966.29 -> AWS-LC and s2n-tls are both available for use on GitHub,

1970.97 -> and on GitHub,

1971.96 -> you can see more details

1973.31 -> about how we specifically implemented the service indicator,

1977.36 -> all of the performance improvements,

1978.92 -> and how s2n-tls managed

1981.14 -> the prefixed internal build of AWS-LC.

1985.4 -> But AWS-LC is also not just useful for AWS.

1989.3 -> We believe it's useful for you, our customers, client-side,

1993.23 -> and there's actually already some existing ways

1995.24 -> you can use AWS-LC,

1997.55 -> such as with the AWS Java SDK.

2000.85 -> This is the existing Java SDK that you use

2003.61 -> when connecting to AWS.

2005.92 -> There's a new version that is built

2007.57 -> on top of the AWS Common Runtime,

2010.24 -> which is a lightweight C library

2012.88 -> that provides common functionality for all of the AWS SDKs.

2017.83 -> And this is built using s2n-tls and AWS-LC,

2021.82 -> so by updating your code to the new AWS Java SDK V2,

2026.05 -> you can take advantage of all of

2027.52 -> the performance and security benefits,

2029.65 -> but still use the same existing Java API

2032.68 -> that you're already familiar with using

2034.69 -> when connecting to AWS.

2037.15 -> And our use cases extend beyond just TLS

2040.69 -> and connections over the internet.

2043 -> For applications that need

2044.8 -> to use cryptography in their application

2047.95 -> for such as for client-side encryption,

2050.2 -> you can use the Amazon Corretto Crypto provider,

2052.81 -> which, again, is a Java library

2054.85 -> that provides the same standard Java

2057.43 -> interface for cryptography that you might already

2059.89 -> be using in your application,

2061.54 -> but is powered by AWS-LC and gets all of the optimizations

2065.62 -> and security benefits of using

2067.75 -> our implementations of those algorithms.

2073.48 -> Here is some more information.

2077.14 -> What I'd like to call out as interesting

2079.03 -> is the link to the Amazon science paper

2081.227 -> "Verified Cryptographic Code for Everyone."

2084.37 -> There, you can learn more about

2085.54 -> our formal verification improvements in AWS-LC

2089.08 -> and the work we did with Galois to verify the algorithms.

2093.61 -> My coworkers also just published a blog post,

2097.906 -> "Preparing Today for a Post-quantum Cryptographic Future"

2100.72 -> that goes into more depth on the recent NIST announcements

2104.47 -> and how AWS-LC is adopting post-quantum cryptography.

2108.16 -> And if you're really

2108.993 -> passionate about post-quantum cryptography,

2111.4 -> we have some re:Invent talks that cover that

2113.65 -> and more talks on FIPS in the Cloud.

2119.8 -> Thank you.

2120.64 -> You can reach out with any questions to [email protected],

2124.12 -> and I'll be hanging around next to the stage

2126.28 -> for any questions or anything

2127.3 -> you'd like to discuss about cryptography.

2130.39 -> And please complete the session survey.

2132.73 -> Thanks for your time.

2134.265 -> (audience applauding)

Source: https://www.youtube.com/watch?v=OLaKGzZAxRM