Internet-Draft License Activation Protocol August 2021
Lorlacks Expires 8 February 2022 [Page]
Workgroup:
Internet Engineering Task Force
Internet-Draft:
draft-lorlacks-license-activation-protocol-00
Published:
Intended Status:
Experimental
Expires:
Author:
M. Lorlacks
Independent

License Activation Protocol

Abstract

This document defines an experimental method for uniform license activation mechanism for use in digital rights management (DRM).

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 8 February 2022.

Table of Contents

1. Introduction

A common issue with on-premises software licensing is ensuring that licensing limitations are enforced. Digital rights management (DRM) is an umbrella term for modeling legal licensing requirements in the form of executable code. Part of DRM implementation is often communication with a server to ensure central knowledge of licenses in circulation.

DRM implementations are in practice almost always one-off solutions for a particular product. No observable efforts to standardize DRM have been made. While DRM necessarily relies on either hardware or on security by obscurity, another use for DRM is to simplify license compliance for honest customers. Consolidating the license information on a single server within an organization brings obvious benefits for keeping track of software inventory, obviating the need of manually triangulating licenses in use.

It therefore seems beneficial to standardize a license management protocol that is both suitable for obfuscation without giving away too much information to active adversaries observing traffic and at the same time has reasonable implementation semantics for simplified cases where active adversaries are ignored, such as when it is too costly to spend great effort on software protection; modern obfuscation techniques are complex and accordingly expensive to implement, see e.g. [virtsc]. The license activation protocol presented herein aims to satisfy both of these needs.

2. Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [BCP14] when, and only when, they appear in all capitals, as shown here.

3. Protocol

The protocol operates between a client and a server in a request-response fashion. The client sends a request and the server sends a response. Both request and response are each UDP datagrams[RFC0768].

The protocol can both be used in a direct setup (customer client and vendor server communicate directly over the Internet) and an indirect setup (customer client and customer intermediate server communicate directly; customer intermediate server and vendor server communicate with each other using this same protocol). Practical considerations may necessitate one or the other setup. The choice between the setups must be made at provisioning time.

3.1. Provisioning

Prior to executing the protocol, every client must first be "provisioned". Provisioning means equipping the client with:

  1. a UUID[RFC4122] that remains static for the installation time of the client (client ID),
  2. unique, hard-to-predict information (client seed),
  3. information about the expected server.

The client ID MUST be generated at installation time. It is RECOMMENDED that a version 4 UUID using a cryptographically secure random number generator is used.

The client-side unique, hard-to-predict information (client seed) is typically supplied and generated at installation time. It could, for example, consist of a unique license key concatenated with hardware information. No format is specified; the actual value of the client seed is out of scope, but it MUST be a byte string consisting of one or more bytes; It is RECOMMENDED to include at least 16 bytes of cryptographically secure random data.

Additionally, the client must be aware of its own stock-keeping unit (SKU) identifier. This is a UUID[RFC4122].

The server information is typically hard-coded at compile time. It consists of an X25519 public key[RFC7748] and an Ed25519 signing key[RFC8032].

3.2. Service Discovery

The license activation server has a DNS SRV record[RFC2782] for the service name "lap", e.g. _lap._udp.licensing.example.com. The record describes the UDP port to use for the protocol. No fixed UDP port is assigned; the UDP port for an individual deployment may therefore be chosen in accordance with IANA policy and the constraints of the network(s) involved.

The license activation server MAY be auto-discovered using DNS-based service discovery (DNS-SD)[RFC6763]. The associated TXT record is empty. Individual clients MUST provide a documented mechanism to manually override an auto-discovered server address.

3.3. Request

Once the client has discovered the license activation server to use (hostname, UDP port), it sends the request. The request has this structure:

Table 1
Size (bytes) Name Description
1 Version Protocol version, currently always 0
2 Size Size of the request in bytes in little-endian byte order
5 ClientTime The client's idea of the current time in Seconds Since the Epoch
16 RequestId Client-generated UUID[RFC4122] uniquely identifying this request
16 ClientId Client-generated UUID[RFC4122] uniquely identifying the client
16 SKUId Stock-keeping unit (SKU) UUID[RFC4122] that identifies the product of the client
(variable) ClientSeed The client seed value

There MUST NOT be any padding between the fields.

If a client-generated UUID contain a timestamp by specification, the timestamp contained therein MUST NOT contradict the ClientDate and ClientTime fields.

The Size field is computed starting at the Version field. Since the client seed (and thus the ClientSeed field) is not permitted to be emptySection 3.1, Paragraph 4, the minimum value for the Size field is 73.

The term "Seconds Since the Epoch" is defined in section 4.16 of the Base Definitions volume of [POSIX.1-2017]; the "Epoch" itself is defined in section 3.150 thereof. "Seconds Since the Epoch" is commonly known as "UNIX time". This field is 5 bytes in length to ensure this protocol working at least until the year 10,000. This integer value is transmitted in little-endian byte order and does not include fractions of a second.

The client then generates an ephemeral X25519[RFC7748] key pair. It performs X25519 with its ephemeral key and the server's public key that was obtained at provisioning time. The nonce and counter values are set to 0. The key is the result of computing a BLAKE2b[RFC7693] hash as follows:

  1. initialize a new BLAKE2b hash context with the following parameters: the key is set to the byte string corresponding to the ASCII encoding of the string "85d40cfd-f9f7-45e8-8f34-21851df92376-LAP-V0" and the output length is set to 32 bytes;
  2. update it with the client's ephemeral X25519 public key;
  3. update it with the server's X25519 public key;
  4. update it with the server's Ed25519 public key;
  5. output the hash.

The encryption key is used with ChaCha20 and Poly1305 (AEAD_CHACHA20_POLY1305)[RFC8439] to encrypt the request. There is no additional authenticated data. The client then transmits:

  1. its 32-byte ephemeral X25519 public key;
  2. the 16-byte Poly1305 authentication tag;
  3. the encrypted request.

The client MUST transmit this information in a single UDP packet, in that particular order and without padding inbetween to the server. This implies that a packet may not exceed the size of what can be transmitted in a single UDP packet.

3.4. Response

Before issuing a response, the server validates the client's request. If the result of the validation process is negative, the server does not respond to the request and drops the UDP packet. Clients MUST NOT probe whether servers drop invalid requests. In particular, the server validates that:

  1. the result of the X25519 function is not all-zero;
  2. decryption succeeded (Poly1305 tag is valid);
  3. the Version field is 0;
  4. the Size field is equal to or greater than 73;
  5. the UUIDs are, in fact, valid UUIDs according to [RFC4122];
  6. if the client-generated UUIDs are version 1 UUIDs, their timestamp field matches the ClientDate and ClientTime fields;
  7. the ClientDate and ClientTime fields match the server's idea of the current time with at most 30 seconds of difference;
  8. the SKU ID is known to the server;
  9. the ClientSeed field is valid according to the rules known to the server;
  10. the client is licensed according to the rules known to the server.

If the validation passes, the server sends the following response structure:

Table 2
Size (bytes) Name Description
1 Version Protocol version, currently always 0
2 Size Size of the response in bytes in little-endian byte order
5 ServerTime The server's idea of the current time in Seconds Since the Epoch in little-endian byte order, see Section 3.3, Paragraph 6
16 ClientId The client-generated UUID echoed back
16 SKUId The SKU ID echoed back
16 LicenseId A UUID[RFC4122] that identifies the license; in case of volume licensing, multiple clients MAY share the same value
(variable) ServerData Application-specific data for the client, which MAY be empty

There MUST NOT be any padding between the fields.

The Size field is computed starting at the Version field, i.e. the very beginning of the message. Since the server data is permitted to be empty, the minimum value for the Size field is 56.

The ServerData field may be used, for example, to transmit a date/time by which the client must consider itself de-activated and needs to re-authenticate or to transmit feature flags that are supposed to be enabled.

The encryption key used by the client is then once more used to encrypt the response. The nonce is set to 1. There is no additional authenticated data. The server then transmits:

  1. its 64-byte Ed25519 signature over the rest;
  2. the 16-byte Poly1305 authentication tag;
  3. the encrypted response.

The server MUST transmit this information in a single UDP packet, in that particular order and without padding inbetween to the client. This implies that a packet may not exceed the size of what can be transmitted in a single UDP packet.

The client finally validates the server response according to the criteria it deems fit, but it MUST at least verify the Ed25519 signature. The client considers itself activated if the response validated successfully.

4. Security Considerations

The client SHOULD NOT be considered trusted. Tampering with DRM is a notorious issue. In particular, as noted in the previous sections, an implementation MUST verify all inputs rigorously. Conversely, the client SHOULD NOT rely on the server's response being well-formed in principle; practical considerations (such as with embedded microprocessors) may necessitate this nonetheless.

All routines and secrets pertaining to DRM SHOULD be protected by hardware-based mechanisms such as trusted platform modules (TPMs), hardware security modules (HSMs), and trusted execution environment technologies. Obfuscation can also aid longevity of DRM by deterring insufficiently motivated attackers.

The server information secrets SHOULD be protected by hardware security modules. Cloud-based hardware security modules MAY be chosen for this task. It is RECOMMENDED that accesses to these keys is monitored; for example, an automated system could cross-reference accesses to the secrets with timing of incoming requests.

While the contents of activation responses in the ServerData field are unspecified, because activation procedures are often time-limited, the accuracy of the client's clock is important. Otherwise, the server may issue responses that are too far into the future or already in the past for the client, bypassing temporal licensing limitations. It is therefore RECOMMENDED that clients synchronize their time over the network, for example using NTP[RFC5905].

In considering an implementation, care should be taken to avoid network amplification attacks. Notably, the server response packet SHOULD NOT exceed the size of a client packet under any circumstances.

5. IANA Considerations

The discovery mechanism described in section Section 3.2 requires a service name. The Service Name and Transport Protocol Port Number Registry therefore needs to be updated accordingly. In accordance with [BCP165], it is hereby requested that IANA create a new entry in the Service Name and Transport Protocol Port Number Registry reading:

Table 3
Service Name lap
Transport Protocols udp
Assignee Maximilian Lorlacks <maxlorlax@protonmail.com>
Contact Maximilian Lorlacks <maxlorlax@protonmail.com>
Description License Activation Protocol
Reference [this document]
Port Number
Service Code
Known Unauthorized Uses
Assignment Notes Defined TXT keys: None.

6. References

6.1. Normative References

[BCP14]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, .
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, .
<https://www.rfc-editor.org/info/bcp14>
[BCP165]
Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, .
Touch, J., "Recommendations on Using Assigned Transport Port Numbers", BCP 165, RFC 7605, .
<https://www.rfc-editor.org/info/bcp165>
[POSIX.1-2017]
IEEE, "Standard for Information Technology--Portable Operating System Interface (POSIX(R)) Base Specifications, Issue 7", IEEE 1003.1, 2017 Edition, DOI 10.1109/IEEESTD.2018.8277153, , <https://ieeexplore.ieee.org/servlet/opac?punumber=8277151>.
[RFC0768]
Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, , <https://www.rfc-editor.org/info/rfc768>.
[RFC2782]
Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, DOI 10.17487/RFC2782, , <https://www.rfc-editor.org/info/rfc2782>.
[RFC4122]
Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 10.17487/RFC4122, , <https://www.rfc-editor.org/info/rfc4122>.
[RFC5905]
Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, , <https://www.rfc-editor.org/info/rfc5905>.
[RFC6763]
Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, , <https://www.rfc-editor.org/info/rfc6763>.
[RFC7693]
Saarinen, M-J., Ed. and J-P. Aumasson, "The BLAKE2 Cryptographic Hash and Message Authentication Code (MAC)", RFC 7693, DOI 10.17487/RFC7693, , <https://www.rfc-editor.org/info/rfc7693>.
[RFC7748]
Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves for Security", RFC 7748, DOI 10.17487/RFC7748, , <https://www.rfc-editor.org/info/rfc7748>.
[RFC8032]
Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, , <https://www.rfc-editor.org/info/rfc8032>.
[RFC8439]
Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF Protocols", RFC 8439, DOI 10.17487/RFC8439, , <https://www.rfc-editor.org/info/rfc8439>.

6.2. Informative References

[virtsc]
Ahmadvand, M., Below, D., Banescu, S., and A. Pretschner, "VirtSC: Combining Virtualization Obfuscation with Self-Checksumming", SPRO '19, Proceedings of the 3rd ACM Workshop on Software Protection pp. 53-64, DOI 10.1145/3338503.3357723, , <https://doi.org/10.1145/3338503.3357723>.

Author's Address

Maximilian Lorlacks
Independent