Penetration Test Report (NCCGroup): NCC Microsoft go cose Report 2022 05 26 v1.0

go-cose Security Assessment
Microsoft Corporation
Version 1.0 – May 16, 2022
© 2022 – NCC Group
Prepared by NCC Group Security Services, Inc. for Microsoft. Portions of this document and the
templates used in its production are the property of NCC Group and cannot be copied (in full or in part)
without NCC Group’s permission.
While precautions have been taken in the preparation of this document, NCC Group the publisher, and
the author(s) assume no responsibility for errors, omissions, or for damages resulting from the use of
the information contained herein. Use of NCC Group’s services does not guarantee the security of a
system, or that computer intrusions will not occur.
Prepared By Prepared For
Gérald Doussot Quim Muntal Diaz
Kevin Henry Steve Lasker
Elena Bakos Lang Josh Watson
Thomas Pornin Roy Williams
Shiwei Zhang
1 Executive Summary
Synopsis
Between the days of April 25th and May 6th, 2022, four (4) consultants from NCC Group
engaged in a security assessment for a total of fifteen (15) person-days of effort reviewing
Microsoft’s contributions to the go-cose library, a Go library implementing signing and
verification for CBOR Object Signing and Encryption (COSE), as specified in RFC 8152. This
library focuses on a minimal feature set to enable the signing and verification of COSE
messages using a single signer, aka “sign1”.
The purpose of this assessment was to identify cryptographic vulnerabilities and
application-level security issues that could adversely affect the security of the go-cose
library. This assessment was performed by NCC Group under the guidelines provided in the
statement of work for the engagement.
Scope
NCC’s evaluation included:
• github.com/veraison/go-cose, commit 8cef769: Primary target of review; a fork of the
go-cose library implementing “sign1” functionality.
• github.com/fxamacker/cbor, v2.4.0: The CBOR library utilized by go-cose. Review was
limited to portions of the API and library functions used directly by go-cose.
Testing Methods
Testing was performed using NCC Group’s standard methodology for a code-assisted
review. Microsoft provided NCC Group with access to source code and documentation in
order to improve the effectiveness of the testing. NCC Group’s consultants used a
combination of manual test techniques and proprietary and public automated tools
throughout the assessment. The following aspects of go-cose were reviewed as part of
this assessment:
• Information leaks through exposed files, APIs, inappropriate error handling, and more
• Business logic and ability to make unauthorized changes
• Encoding-related issues, such as message canonicalization and serialization attacks
• Identification of threats to the cryptosystem and the risks associated with threats, such
as ways for an attacker to:
◦ Obtain inappropriate access to cryptographic keys and sensitive and/or protected
information
◦ Tamper or otherwise influence protected information
• Implementation of cryptographic primitives, including the following:
◦ Selection of cryptographic primitives and algorithms
◦ Appropriate use of standard libraries or implementations
◦ Validation of parameters to cryptographic algorithms
◦ Use of random numbers for cryptographic operations
• Cryptographic protocol sequences and data flows, including the following:
◦ Authentication and/or identification of protocol participants
◦ State management, with emphasis on invalid state transitions
◦ Malicious tampering, re-ordering, and replaying of protocol messages
• Side channels in cryptographic primitives and protocols:
◦ Timing attacks at the protocol, primitive, and underlying library level
◦ Oracle attacks, such as the use of padding and compression oracles
2 / 19 – Executive Summary
Key Findings
During the assessment, NCC Group identified:
1. One informational finding, Signature Size May Be Incorrect For Some Curves: For some
elliptic curves, the encoded signature size may be incorrect, leading to interoperability
issues or rare failures. The standard NIST curves (P-256, P-384 and P-521) are not
affected. This issues has subsequently been fixed.
2. A detailed listing of requirements and recommendations from RFC 8152 relevant to go-
cose, with an explanation of how go-cose has addressed them, where applicable.
3. A detailed documentation review and minor comments that did not warrant standalone
findings, but that are likely of interest to the go-cose team.
Strategic Recommendations
Upon completion of the assessment, all findings were reported to Microsoft along with
recommendations:
• Ensure all function documentation is consistent, clear, and concise. In general, functions
and requirements are well-documented, but an editing pass for correct grammar and
consistency would improve the quality of the documentation.
• Consider providing safer interfaces for common user-facing functionality. Features such
as new algorithm registration may be unsafe in some situations, such as in multi-
threaded contexts. Adherence to RFC requirements also relies on the user not modifying
a message after signing, which suggests a SignAndMarshalCBOR() interface may be
safer than distinct Sign() and MarshalCBOR() functions for the “sign1” use case.
• It was observed that the library supports duplicate labels across the protected and
unprotected portions of the header, in direct contradiction to the RFC. While the
provided interface within the library facilitates safe usage, higher level libraries may
merge header fields, potentially creating ambiguity. Consider enforcing uniqueness of
labels across the entire header or updating documentation to clearly highlight the
implemented behavior.
Retest Results
Following initial reporting of these issues to Microsoft, NCC Group reviewed several pull
requests in accordance with the above methodology and observed that the reported issues
were effectively addressed.
3 / 19 – Executive Summary
2 Dashboard
Target Data Engagement Data
Name go-cose Type Security Assessment
Type Security Library Method Cose-assisted
Platforms Go Date 2022-04-20
Environment Local Consultants 4
Targets
veraison / go-cose A fork of the go-cose library that adds sign1 support.
Finding Breakdown
Critical issues 0
High issues 0
Medium issues 0
Low issues 0
Informational issues 1
Total issues 1
Category Breakdown
Cryptography 1
Critical High Medium Low Informational
4 / 19 – Dashboard
3 Table of Findings
For each finding, NCC Group uses a composite risk score that takes into account the
severity of the risk, application’s exposure and user population, technical difficulty of
exploitation, and other factors.
Title Status ID Risk
Signature Size May Be Incorrect For Some Curves Fixed 6XB Info
5 / 19 – Table of Findings
4 Finding Details
Signature Size May Be Incorrect For Some
Info
Curves
Overall Risk Informational Finding ID NCC-E002762-6XB
Impact Low Category Cryptography
Exploitability None Status Fixed
Impact
For some elliptic curves, the encoded signature size may be incorrect, leading to
interoperability issues or rare failures. The standard NIST curves (P-256, P-384 and P-521)
are not affected.
Description
An ECDSA signature consists of a pair of integers (r, s); the two integers are in the 1 to q-1
range, where q is the order of the subgroup of the elliptic curve in which the signature is
computed. In COSE, such a signature is encoded into bytes using the following process,
described in RFC 8152:
The signature algorithm results in a pair of integers (R, S). These
integers will be the same length as the length of the key used for
the signature process. The signature is encoded by converting the
integers into byte strings of the same length as the key size. The
length is rounded up to the nearest byte and is left padded with zero
bits to get to the correct length. The two integers are then
concatenated together to form a byte string that is the resulting
signature.
Using the function defined in [RFC8017], the signature is:
Signature = I2OSP(R, n) | I2OSP(S, n)
where n = ceiling(k