Penetration Test Report (TrailOfBits): SweetB

Sweet B
Security Assessment
January 24, 2020
Prepared For:
Brian Mastenbrook | W​ estern Digital
Brian.Mastenbrook@wdc.com
Prepared By:
Sam Moelius | ​Trail of Bits
sam.moelius@trailofbits.com
Jim Miller | ​Trail of Bits
james.miller@trailofbits.com
Paul Kehrer | ​Trail of Bits
paul.kehrer@trailofbits.com
Executive Summary
Project Dashboard
Engagement Goals
Coverage and Compliance
Recommendations Summary
Short Term
Long Term
Findings Summary
1. Assembly does not work in all build configurations
2. Use of libc functions that may not be constant time
3. Enabling of SB_DEBUG_ASSERTS violates constant time behavior
4. HMAC_DRBG may lack backtracking resistance
5. Use of functions on the SDL List of Banned Functions
6. API for ECDSA signatures does not enforce secure message digests
A. Vulnerability Classifications
A. Non-Security-Related Findings
B. Instruction Trace Analysis
Methodology
Limitations
Results
C. Unit Test Coverage Analysis
D. Build Configuration Analysis
© 2020 Trail of Bits Western Digital Sweet B Assessment | 1
Executive Summary
From January 13 through January 24, 2020, Trail of Bits reviewed the security of Sweet B, a
library that provides elliptic curve operations over 256-bit prime fields and a set of
supporting hash-based primitives. Trail of Bits conducted this assessment over the course
of four person-weeks with three engineers working from commit ​02d41f4d of ​sweet-b.
​ ​
During the first week, we verified we could build and run tests for the codebase, then
evaluated the output for several static analyzers on the code. We identified functions
expected to have constant-time behavior for further testing and manually reviewed ​SHA256,
​
HMAC_SHA256, ​HMAC_DRBG, and ​HKDF for security and compliance with relevant standards.
​ ​ ​
In discussions with Western Digital, we identified an opportunity to provide empirical
evidence that Sweet B maintains two important security properties: that certain functions
maintain constant-time behavior and that the library works as expected in many build
scenarios.
During the second week, we used a modified version of QEMU to obtain instruction traces
for functions where constant runtimes were a concern. We verified that the instruction
traces did not vary with the input to the function. We also checked those instruction traces
for certain problematic instructions.
Figure 1: We tested Sweet B in a manner similar to fuzzing to identify possible timing issues
Instruction trace analysis identified a potential misconfiguration that could produce
functions that are not constant time (T​ OB-SB-001​) and that undue trust was placed in the
behavior of certain l​ ibc functions (​TOB-SB-003)​ . See A​ ppendix C​ for more details.
​
We performed a differential analysis of possible build configurations to ensure the
compiled results did not produce unexpected or broken behavior. Compiler output and
unit tests provided the basis for evaluation of different builds.
© 2020 Trail of Bits Western Digital Sweet B Assessment | 2
Figure 2: We performed differential testing of possible build configurations
Build configuration analysis identified that the library could produce incorrect results and
possibly read memory out-of-bounds due to certain assembly instructions (T​ OB-SB-004​).
See A​ ppendix E ​for more details.
We also more closely reviewed the unit tests provided with Sweet B. We performed code
coverage analysis of the unit tests to identify possible gaps in those tests, then
recommended areas for improvement. See ​Appendix D​ for more details.
Finally, we completed manual review of the elliptic curve and prime-field implementations.
We identified potentially error-prone functions (T​ OB-SB-002​) and issues related to the
ECDSA API (​TOB-SB-005)​ . We found no issues regarding standards compliance.
Throughout our review, the quality and abundance of the comments within the code
significantly aided our diagnoses of the issues we found.
© 2020 Trail of Bits Western Digital Sweet B Assessment | 3
Project Dashboard
Application Summary
Name Sweet B
Version 02d41f4d
Type C, Thumb assembly
Platforms ARM
Engagement Summary
Dates January 13 through 24, 2020
Method Whitebox
Consultants Engaged 3
Level of Effort 4 person-weeks
Vulnerability Summary
Total High-Severity Issues 0
Total Medium-Severity Issues 1 ◼
Total Low-Severity Issues 3 ◼◼◼
Total Informational-Severity Issues 2 ◼◼
Total 6
Category Breakdown
Configuration 1 ◼
Cryptography 2 ◼◼
Data Validation 1 ◼
Timing 2 ◼◼
Total 6
© 2020 Trail of Bits Western Digital Sweet B Assessment | 4
Engagement Goals
The engagement was scoped to provide a security assessment of standards compliance,
constant time behavior, unit testing, build configuration, and safety/usability of the API.
Specifically, we sought to answer the following questions:
● Do the functions properly implement their respective standards?
● Do the constant time functions produce identical instruction traces when presented
with distinct inputs?
● Are there gaps in the unit tests?
● Do the unit tests pass under all possible build configurations?
● Are there aspects of the API that seem error-prone or unintuitive?
Coverage and Compliance
This section discusses our manual coverage of the Sweet B codebase. Specifically, we
describe which components we analyzed to determine their compliance with their
corresponding specifications. We also comment on test vectors and unit tests supplied for
the corresponding primitives.
SHA256: ​Trail of Bits reviewed the code corresponding to Sweet B’s S​ HA256 implementation
​
and its corresponding test vectors. Test vectors were supplied from both ​FIPS 180-2​ and
the N​ IST cryptographic algorithm validation program (CAVP).​ These vectors are designed to
exercise potential edge cases in the algorithm and provide some assurance of
implementation correctness. The Sweet B code passes all of these test cases. The
implementation was also assessed for its compliance with the ​NIST FIPS 180-4 standard.​
Specifically, this review determined if the implementation’s parameters (e.g., word size) and
general interface comply with the NIST standard.
HMAC_SHA256:​ Trail of Bits reviewed the code and corresponding test vectors for Sweet
B’s ​HMAC_SHA256 implementation. The implementation passes all test cases, with test
​
vectors supplied from Internet Engineering Task Force (IETF) ​RFC 4231.​ This
implementation’s parameters and general interface were also assessed for their
compliance with N​ IST FIPS 198-1.​
HMAC_DRBG:​ Trail of Bits additionally reviewed the code and test vectors for Sweet B’s
HMAC_DRBG implementation. The implementation passes all tests, with test vectors supplied
​
from the N​ IST CAVP.​ Our review ensured that parameters fixed by the implementation and
parameters adjustable by users only take values that are in accordance with N​ IST SP 800-90
standards. Further, this review determined whether the implementation interface and
© 2020 Trail of Bits Western Digital Sweet B Assessment | 5
error-handling comply with the standard. I​ t has been shown​ that H​ MAC_DRBG, even when
​
compliant with N​ IST SP 800-90,​ is not backtracking-resistant when additional input is not
required upon generating random bits. See T​ OB-SB-006​ for more details.
HKDF:​ Trail of Bits also reviewed the code and test vectors for Sweet B’s ​HKDF
implementation. This implementation was assessed for its compliance with ​NIST SP
800-108 ​and I​ ETF RFC 5869​. The test vectors were obtained from ​IETF RFC 5869​, and the
Sweet B code passes of all these test cases. This review ensured that both the parameters
and interface complied with the appropriate standards. In particular, this review verified
that the interface handles special inputs correctly, such as a ​NULL salt.
​
P-256, secp256k1: ​Trail of Bits reviewed the instantiation of two elliptic curves, P​ -256 and
​
secp256k1, used throughout the Sweet B codebase. ​P-256 was assessed for its compliance
​ ​
with ​NIST FIPS 186-4​, and s​ ecp256k1