OpenC2 Message Signature

[dmg2]

TLDR; we should sign our OpenC2 messages to ensure message integrity.

As OpenC2 matures its important that we look at security considerations as they relate to OpenC2 messages. Although encryption can and generally is handled by transfer protocols, message integrity, authentication, and non-repudiation are still in question. Multiple similarly designed protocols within Oasis have come to this conclusion including, SAML 2.0. Additionally due to attack vectors such as man-in-the-middle (MitM) and MitM network services which are prevalently used by network defenders today we recognize as a community that encryption alone does not suffice. Message integrity is extremely important in many of the DoD related use-cases and in order to meet this need, we suggest that addition of a signature based mechanism to be carried within the message.

Recommendation is that we add a section called signature which is Recommended, but not required. In this field the producer will use a hash algorithm to create a message digest which will then be encrypted by the producers private key. The consumer will utilized the producers public key, also provided in the message, to decrypt the message digest in order to compare it to the message digest it calculates from the message using the same algorithm as above. If both message digest are equivalent then we assume that message integrity was preserved from sender to receiver. We realize that this method can still be subverted if the Certificate Authority is not properly set up or preserved, however we believe that is out of scope for OpenC2 and should be assumed to be working as per normal set up of a network environment.

For responses there are 2 potential methods. (I prefer method 2, but...)

1. Utilize producers public key to sign response back to the producer from the consumer.
2. Utilize consumers private key to sign response back to the producer from the consumer.

Method 1 the response indicates that it was meant for that producer, somewhat useful. However it does alleviate the need of a individual key by the consumers.
Method 2 the response indicates that it came from the specific consumer, very helpful. However it adds extra complexity by requiring all consumers to hold a private certificate signed by a reputable source.

Double signing / (signing with both private key and recipients public key), although a superior method, is not recommended because it would limit the 1 to many functionality of OpenC2.

[Vasileios-Mavroeidis]

I second the need of having a mechanism for integrity and the proposed implementation sounds good.

Regarding the responses. The second method looks more secure. Hypothetically in a scenario that we bridge the confidentiality of a message, having implemented the first method, we can alter the response of the message since we hold the public key that the digest was signed and is part of the OpenC2 message. So an attacker can send a 200 response back to the producer when a consumer has not executed or even received the message.

The second method is more secure, since a response needs to be signed using the private key of a consumer. The producer holds the public keys of the consumers.

"We realize that this method can still be subverted if the Certificate Authority is not properly set up or preserved, however we believe that is out of scope for OpenC2 and should be assumed to be working as per normal set up of a network environment." <<==== or in the case of a transport that does not have any mechanism for preserving the confidentiality of the communication. That actually will need to be specified in the specification, such as that it doesnt make sense to have an integrity mechanism installed when the confidentiallity of the message is not preserved by the transport.

[davaya]

A communications environment that provides "confidentiality and integrity" without authentication does not actually provide either, because an adversary can spoof any unauthenticated participant. Even if a user connects via certificate-based TLS to a bank, the user still needs 1 or 2 factor entity authentication or signature-based data origin authentication as proposed here.

In a communications environment that provides no security (e.g., http), signature-based data origin authentication is still effective. Anyone can read messages going by, but nobody can successfully modify them. Confidentiality is not required.

And whether or not transport provides confidentiality, message signatures provide integrity for data at rest long after the transport is finished.

[Vasileios-Mavroeidis]

A communications environment that provides "confidentiality and integrity" without authentication does not actually provide either, because an adversary can spoof any unauthenticated participant. Even if a user connects via certificate-based TLS to a bank, the user still needs 1 or 2 factor entity authentication or signature-based data origin authentication as proposed here.

You are describing a reasonable extra layer of security. Still, with certificates, we can have mutual authentication as long as the certificates at the endpoints are not compromised (producer/consumer). It would be the same with a username, password, or a token (keep them safe :P)

In a communications environment that provides no security (e.g., http), signature-based data origin authentication is still effective. Anyone can read messages going by, but nobody can successfully modify them. Confidentiality is not required.

Brainstorming the scenario; this is the case for the second method that was described. The first method allows you to alter the response message since the consumer will use the producer's public key to sign the message.

[dmg2]

Just a note: As a related security concern we should explore Methods to prevent replay.

[dlemire60]

I found some interesting thoughts about message signature challenges in this article. https://latacora.micro.blog/2019/07/24/how-not-to.html

albeit with something of a focus on AWS API calls as the example application.

[dmg2]

I created a notional solution, I emailed it to the OpenC2-Comments email list. However it was brought to my attention that not everyone subscribes to that email list so I decided to put the solution here as well.
https://github.com/dmg2/OpenC2-Signatures

[dlemire60]

At some point we'll have to recognize and address the fact that any message signature solution is probably only applicable to a single serialization format. So @dmg2's proposal looks good for JSON, but what do we use for CBOR? Do we need to consider a separate work product to standardize message signature mechanisms for multiple serializations?

[dlemire60]

discussed at triage. would like to include in next version, but would also like to be consistent with CACAO and CTI signature solutions. Tagging as next version, but timeline will be driven by the other TCs, so may get pushed to future.

Participation in the other TCs would be helpful.

[dlemire60]

I've been looking at IETF materials and realized that there are solutions for both JSON and CBOR.

• JSON Object Signing & Encryption (JOSE working group link)
• CBOR Object Signing & Encryption (COSE working group link)

The solution described by DMG2 and included in the working version references some of the JOSE documents. We should make sure we're applying them properly and consider using the COSE documents in a similar manner to accompany CBOR encoding.

[dlemire60]

The current (27 July 2022) working version includes requirements for JSON message signatures (section 3.3.4) and examples of creating and validating message signatures (section C.4).

Missing and needed are conformance requirements regarding message signatures.

[dlemire60]

One of our triage outcomes was a goal to "be consistent with CACAO and CTI signature solutions". Reviewing:

• CACAO Security Playbooks, v1.0, CS02 includes signing guidance using JWS very similar to the OpenC2 LS working version; see section 2.6 and Appendix A.2 of the CACAO spec.
• The STIX 2.1 OS doesn't include any form of cryptographic protections for STIX objects
• The TAXII 2.1 OS uses HTTPS authentication methods as defined in RFC 7235 and RFC 7617; see section 1.6.9 of the TAXII spec.

Input from participants in the CACAO and CTI TCs is needed regarding plans for expanded security mechanisms for any of theses specifications.

[dlemire60]

The new CACAO 2.0 Spec (public review announcement) contains solid information about signatures, including numerous RFC references that we could leverage. It's focus is purely on signing JSON formatted content, since that's how CACAO playbooks are written. Bret Jordan also mentioned a (forthcoming?) ITU-T standard that we could potentially apply.

[dlemire60]

PR #430 updates the draft v2.0 text to use the newly approved ITU-T X.590 JSON Signature Schema.

Recommend this issue be closed.

[dlemire60]

This issue is now closed, per consensus at the 10 January 2024 working meeting.