Deliverable D8.4 Certificate Transparency Log v2.0 Production Service

Similar documents
Google Cloud & the General Data Protection Regulation (GDPR)

Public Key Infrastructures

Deliverable D8.7 Network Management as a Service Production Service

GÉANT Interconnection Policy Reference <GA(18)005 >

Network Disaggregation

EU Liaison Update. General Assembly. Matthew Scott & Edit Herczog. Reference : GA(18)021. Trondheim. 14 June 2018

Advancing European R&E through collaboration

Chapter 4. Fundamental Concepts and Models

SWITCHpki Service Launch The SWITCHpki Team

Intended status: Experimental Expires: July 18, 2018 T. Ritter January 14, 2018

VdTÜV Statement on the Communication from the EU Commission A Digital Single Market Strategy for Europe

Intended status: Experimental Expires: January 9, 2017 T. Ritter. July 08, 2016

Deliverable D8.2 Firewall-on-Demand Progress Report

DIGITALSIGN - CERTIFICADORA DIGITAL, SA.

Accelerate Your Enterprise Private Cloud Initiative

Version 11

INCOMMON FEDERATION: PARTICIPANT OPERATIONAL PRACTICES

NATIONAL CYBER SECURITY STRATEGY. - Version 2.0 -

GRIDS INTRODUCTION TO GRID INFRASTRUCTURES. Fabrizio Gagliardi

Security and resilience in Information Society: the European approach

Cybersecurity ecosystem and TDL Antonio F. Skarmeta

SERVICE DESCRIPTION. Population Register Centre s online services

WAVE: A Decentralized Authorization Framework with Transitive Delegation

eduroam Managed IdP Product Presentation

FEDERICA Federated E-infrastructure Dedicated to European Researchers Innovating in Computing network Architectures

Trust Service Provider Technical Best Practices Considering the EU eidas Regulation (910/2014)

Evaluation and lessons learnt from scenario on Real-time monitoring, reporting and response to security incidents related to a CSP

Data Center Management and Automation Strategic Briefing

GN4-2 SA2 Kick-Off Meeting Amsterdam/NL 30/

Deliverable D4.2. Open Source Management Charter Template. ICT Project. The European Open Source Market Place.

Village Software. Security Assessment Report

SHA-1 to SHA-2. Migration Guide

INCOMMON FEDERATION: PARTICIPANT OPERATIONAL PRACTICES

GÉANT3 Services. Ann Harding, SWITCH TNC Connectivity and Monitoring Services by and for NRENs. connect communicate collaborate

GN3plus External Advisory Committee. White Paper on the Structure of GÉANT Research & Development

IPv6 Task Force - Phase II. Welcome

ARE YOU READY FOR GDPR?

ENISA EU Threat Landscape

Layer Security White Paper

1. Federation Participant Information DRAFT

TECHNICAL WHITE PAPER FIDO APPROACHES: NOK NOK LABS S3 SUITE VS BUILD YOUR OWN FIDO

Deliverable 7.1 M3 m-resist website

DECISION OF THE EUROPEAN CENTRAL BANK

SOC for cybersecurity

BEYOND AUTHENTICATION IDENTITY AND ACCESS MANAGEMENT FOR THE MODERN ENTERPRISE

SCION: PKI Overview. Adrian Perrig Network Security Group, ETH Zürich

InCommon Federation: Participant Operational Practices

INCOMMON FEDERATION: PARTICIPANT OPERATIONAL PRACTICES

First Session of the Asia Pacific Information Superhighway Steering Committee, 1 2 November 2017, Dhaka, Bangladesh.

GÉANT Community Programme

FAQ about the General Data Protection Regulation (GDPR)

Workpackage WP 33: Deliverable D33.6: Documentation of the New DBE Web Presence

Trusted Identities. Foundational to Cloud Services LILA KEE CHIEF PRODUCT OFFICER GLOBALSIGN

IT Enterprise Services. Capita Private Cloud. Cloud potential unleashed

INCOMMON FEDERATION: PARTICIPANT OPERATIONAL PRACTICES

e-infrastructures in FP7 INFO DAY - Paris

Cybersecurity eit. Software. Certification. Industrial Security Embedded System

Security Overview. Technical Whitepaper. Secure by design. End to end security. N-tier Application Architecture. Data encryption. User authentication

Integration of Network Services Interface version 2 with the JUNOS Space SDK

JRA5: Roaming and Authorisation

European Interoperability Reference Architecture (EIRA) overview

ISSUES FOR RESPONSIBLE USER-CENTRIC IDENTITY

SERVICE DESCRIPTION MANAGED FIREWALL/VPN

Technical Overview. Version March 2018 Author: Vittorio Bertola

INCOMMON FEDERATION: PARTICIPANT OPERATIONAL PRACTICES

Technical Brief SUPPORTPOINT TECHNICAL BRIEF MARCH

GN2 JRA5: Roaming and Authorisation

DATA CENTRE SOLUTIONS

Work Package 6 Dissemination and Exploitation Involved Partners: Planet Media, City Passenger, LTU, CTI

Table of Contents. Blog and Personal Web Site Policy

Agenda GDPR Overview & Requirements IBM Secure Virtualization Solution Overview Summary / Call to Action Q & A 2

Service Sharing at NORDUnet

Qualification Specification

Introduction. Delivering Management as Agile as the Cloud: Enabling New Architectures with CA Technologies Virtual Network Assurance Solution

NEW USER GUIDE. 1 February 2019

AWS SECURITY AND COMPLIANCE QUICK REFERENCE GUIDE

INCOMMON FEDERATION: PARTICIPANT OPERATIONAL PRACTICES

ANZPAA National Institute of Forensic Science BUSINESS PLAN

Blockchain for Enterprise: A Security & Privacy Perspective through Hyperledger/fabric

Digital Security. Rafael Tesoro Carretero DG CNECT, Unit H1 - Cybersecurity & Digital Privacy

Project Title: INFRASTRUCTURE AND INTEGRATED TOOLS FOR PERSONALIZED LEARNING OF READING SKILL

ING PUBLIC KEY INFRASTRUCTURE CODE OF CONDUCT FOR EMPLOYEE CERTIFICATES. Version November ING PKI Service

The Migration to Ipv6

INCOMMON FEDERATION: PARTICIPANT OPERATIONAL PRACTICES

SURFnet network developments 10th E-VLBI workshop 15 Nov Wouter Huisman SURFnet

H2020 WP Cybersecurity PPP topics

New Zealand Government IBM Infrastructure as a Service

INCOMMON FEDERATION: PARTICIPANT OPERATIONAL PRACTICES

HALO IN ACTION COMPLIANCE DON T LET LEGACY SECURITY TOOLS HOLD UP PCI COMPLIANCE IN THE CLOUD. Automated PCI compliance anytime, anywhere.

Certification Practice Statement of the Federal Reserve Banks Services Public Key Infrastructure

INFORMATION EXCHANGE GATEWAYS: REFERENCE ARCHITECTURE

Memorandum of Understanding

AARC Overview. Licia Florio, David Groep. 21 Jan presented by David Groep, Nikhef.

Twilio cloud communications SECURITY

Multi-Domain VPN service, a seamless infrastructure for Regional Network, NRENs and GEANT

H2020 Opportunities in the Area of Security and Critical Infrastructure Protection

Blue Alligator Company Privacy Notice (Last updated 21 May 2018)

INCOMMON FEDERATION: PARTICIPANT OPERATIONAL PRACTICES

IoT privacy risk management in ANASTACIA project

Module Shared API and Core Services

Transcription:

16-11-2017 Certificate Transparency Log v2.0 Production Contractual Date: 31-10-2017 Actual Date: 16-11-2017 Grant Agreement No.: 731122 Work Package/Activity: 8/JRA2 Task Item: Task 6 Nature of Deliverable: O (Other) demo Dissemination Level: PU (Public) Lead Partner: DFN (LRZ) Document ID: GN4-2-17-16C404 Authors: L. Nordberg (NORDUnet), M. Ahltorp (NORDUnet), I. Golub (PSNC), D. Schmitz (DFN (LRZ)) GEANT Limited on behalf of the GN4-2 project. The research leading to these results has received funding from the European Union s Horizon 2020 research and innovation programme under Grant Agreement No. 731122 (GN4-2). Abstract This document gives an overview of the GÉANT Certificate Transparency (CT) log service being developed by JRA2 T6, a new IETF standards-based approach to discover misissued certificates. It explains CT and describes the CT log service, its benefits and users, technology and architecture, and operational aspects. It also provides a roadmap for GN4-2 Period 2.

Table of Contents Executive Summary 1 1 Introduction 2 2 Certificate Transparency 3 2.1 Certificate Transparency 3 2.2 Description 3 2.3 Benefits 4 2.4 Users 5 3 Technical Description 6 4 Operations 8 4.1 Supporting Infrastructure 8 4.2 Operations and Support Teams 8 4.3 Policies 9 4.4 Metrics 9 5 Roadmap 10 6 Conclusions 11 References 12 Glossary 12 Table of Figures Figure 3.1: CT log server architecture 6 ii

Executive Summary The GÉANT Certificate Transparency (CT) log service is a new development in GN4-2, and continues work originally started by SUNET/NORDUnet. It is a new, Internet Engineering Task Force (IETF) standards-based approach to discover misissued certificates. By providing transparency of all issued certificates through the log, the CT log service enables its users domain owners, certification authorities (CAs), browser vendors and web users to monitor and audit the certificates for any given domain. This helps to strengthen the trust and security of the web space and thus of the Internet as a whole. Additional benefits that this service brings to the community are direct control over service availability; low latency for accessing the service; the potential for retrieval of research data, taking privacy concerns into account; increased legitimacy for CT in general, resulting in a more secure web; and increased trust among entities participating in the CT log service. The GÉANT Certificate Transparency log service has three main aspects: installation of the CT log server, and providing two types of support to users: in using the service and/or in contributing to the GÉANT CT log service by providing CT architecture components in their own domain. This document gives an overview of the Certificate Transparency log service that is being developed in GN4-2. It describes how it is structured, the benefits of the service, and to whom it is offered. It covers the technical background of the service, as well as the operational aspects, namely, supporting infrastructure, service policies, service metrics, and operations and support teams. The document also provides a service roadmap for GN4-2 Period 2, and concludes with an overall assessment of the service. The GÉANT Certificate Transparency log service is planned for production in spring 2018. 1

1 Introduction Certificate Transparency (CT) is a new, Internet Engineering Task Force (IETF) standards-based approach to discover the misissuance of domain certificates by using a public, append-only log. Malicious or undependable certification authorities (CAs) can create certificates for a domain without the knowledge, instruction or approval of the domain owner. CT provides a tool to detect such actions and can thus help in their fast and successful resolution. The development of a CT log server by Joint Research Activity 2 Network s Development, Task 6 Network Security (JRA2 T6) during Period 1 is a continuation of work begun by SUNET/NORDUnet prior to GN4-2. The development is shaped towards supporting and delivering the GÉANT Certificate Transparency log service, which is scheduled to transition into production during Period 2. This document gives an overview of the CT log service that GÉANT will provide to its users; a demonstration of the production service 1 will be scheduled once that transition has taken place. Section 2 describes the service, beginning with an explanation of CT and including the service s benefits and users. Section 3 provides a technical description and Section 4 considers service operations, covering supporting infrastructure, operations and support team, policies and metrics. Section 5 explains the Certificate Transparency service roadmap for GN4-2 Period 2. Section 6 presents an overall assessment of the service. 1 Other: demo was the Type stated in the Technical Annex for this deliverable. 2

2 Certificate Transparency 2.1 Certificate Transparency Certificate Transparency is a system for storing website certificates in public, append-only untrusted logs, as described in IETF RFC 6962 [RFC6962]. CT is recognised by browser vendors and certification authorities as an important and innovative technology that increases trust in the general Internet, including R&E networking. An important effect of CT is that domain owners are able to monitor logs for certificates issued for their domains. They can thus see the certificates that they are using, but also potential certificates that have been issued without their knowledge. This provides a novel and powerful tool for domain owners to control the certificates issued for their domain. Web browsers and other HTTPS clients that use CT require certificates to be present in a number of public logs in order to trust and use them. This makes it possible to efficiently detect and prove misissuance of certificates. Every entity that handles a certificate can submit it to a log, together with the certificate chain from a known certification authority (CA). This means that CAs, web browsers, web server operators and other entities that see a certificate can submit a certificate to CT logs. The append-only property of a CT log means that an entry in a log never changes, is never removed and is never moved to another position in the log. This fundamental property of a log is easily checked by asking the log for proofs which can be verified without the need for any trust in the log itself. By adding a hash of each log entry to a Merkle tree and signing the tree head with the log key, log servers make it possible for auditors to efficiently verify the consistency of the log by retrieving inclusion and consistency proofs from the log and making the same calculations themselves. 2.2 Description The GÉANT Certificate Transparency log service has several work areas: To establish, provide, maintain and manage a central CT log server, open for anyone to submit certificates to it or to check existing certificates within it. In the production service, the log will be configured to accept certificates signed by CAs in all the common trust stores. To provide support to the GÉANT community in understanding how CT logs can help them to protect their network and contribute to strengthening Internet security, as well as to provide 3

Certificate Transparency help in using the log to protect the web space of the domain owners, primarily from the GÉANT community. To provide support to organisations, primarily from the GÉANT community, that want to contribute to the GÉANT CT log service by establishing and running a Certificate Transparency architecture component themselves. GÉANT is a vendor-independent party that supports the interests of all targeted users of the CT log service, which might not be the case with logs that are run by CAs or browser vendors. Currently, not all logs accept all certificates. For example, CAs typically run their own log instance accepting certificates signed by themselves in order to comply with browser requirements. They might (although not very often seen in practice) or might not accept certificates published by other CAs, for whatever reason they choose - technical, economic, political... The GÉANT CT log service equally and equitably supports any web-related party, entity, organisation or person. It also accepts all certificates from all well-known trust stores. By being open to any organisation or user group, the GÉANT CT log service helps in reducing the number of logs one has to search through. Considering that the provided service is available and reliable, with all the aforementioned aspects, GÉANT CT log service will help to improve the certificates verification process. However, even though the service is open and available for all Internet users, the support in how to use the service and how to contribute to CT infrastructure is aimed primarily for the GÉANT community. Apart from maintaining the central CT server and providing help in using the CT log to check the certificates for their domain, GÉANT also provides support to institutions to run a part of the infrastructure themselves. For example, an NREN component of the CT log will provide higher availability and performance of the CT service, especially to the domain owners associated with that NREN, as they are from the routing perspective closer to the log. It will thus enable more direct access to, exploitation and leverage of the benefits. 2.3 Benefits The provision of a central GÉANT CT log service has multiple benefits for all parties involved in its provision and use: 1. Increasing legitimacy for CT in general, resulting in a more secure web. 2. Increasing trust among entities participating in the CT log service 3. Direct control over service availability. 4. Low latency for traffic towards the service. 5. Knowledge-building in the field of CT. 6. Potential retrieval of research data, taking privacy concerns into account. Currently, the only provider of CT logs open to all CAs is Google. However, in order to enhance the transparency and trustworthiness of assigned certificates, which leads to stronger security for each domain, there should be more logs available than just Google s. GÉANT, as an independent and non- 4

Certificate Transparency biased provider, can help all involved parties in strengthening overall web security, thus leading to a more secure Internet. 2.4 Users CT users range from web browsers, domain owners, CAs and browser vendors to all Internet end users. Any of them can at any time be in any of the following roles: log auditor, log monitor, or log contributor. Web browsers and domain owners do not use CT log servers directly but rather through CT log monitors, which periodically fetch all new certificates from one or more CT logs and alert domain owners if a certificate has been issued for their domain. CAs are encouraged to submit new certificates to logs directly. They can benefit from having access to logs that accept their certificates, as well as from predictable availability. Currently, the only browser that uses CT is Chrome, which requires a certificate to be logged in at least two logs in order to consider it trustworthy, one of which has to be a non-google log. Having GÉANT as such a second log places GÉANT in a strong strategic position, especially taking into consideration that this is, at the moment, pioneering work. In the GÉANT community, most NRENs are in the role of domain owners and web users. Some NRENs also have the role of a CA. It is also expected that some NRENs will set up their own CT log monitoring systems and point them at the GÉANT CT log service as a service for the organisations they support universities, research institutes and their other domain owners. NRENs interested in participating in operating parts of the GÉANT CT log service can do so by providing the necessary infrastructure and NOC resources. 5

3 Technical Description The GÉANT CT log service consists of one CT log server [RFC6962] as defined by the architecture of the catlfish [catlfish] software, originally developed by NORDUnet. The catlfish architecture defines three distinct types of nodes: Frontend, Merge and Sign, as presented in Figure 3.1. In the interest of security, the service design minimises the number of components that must be trusted. Figure 3.1: CT log server architecture The GÉANT CT log service will need more than one of every type of node in order to fulfil the redundancy and performance requirements. Frontend nodes are the public-facing nodes. Each Frontend node has a complete copy of the published log, which enables them to answer any read queries (read operations) without referring to other nodes. They are also responsible for coordinating submissions (write requests), forwarding the data to all other Frontend nodes and finally requesting a promise of publication from a Sign node. Frontend nodes are designed to be run at sites that are not fully trusted, and a single Frontend node cannot by 6

Technical Description itself compromise the integrity of the log. Each additional Frontend node provides both added redundancy and performance resilience. Merge nodes are at any one time divided into one Primary Merge Node and the Secondary Merge Nodes. The Primary Merge Node periodically collects the submissions gathered at the Frontend nodes and decides the order in which the submissions should be published. After having sent the order to the Secondary Merge Nodes, the Primary Merge Node then requests a publication signature from a Sign node and distributes the signature and the order to all Frontend nodes. Any submission missing from a Frontend node is also distributed to that Frontend node by the Primary Merge Node. If the Primary Merge Node fails, a new Primary Merge Node is selected from among the Secondary Merge Nodes. Sign nodes have the cryptographic keys that are the basis of the cryptographic trust of the log. They issue two types of signature: promises of publication (Signed Certificate Timestamp (SCT)) and publication signatures (Signed Tree Head (STH)). The Sign nodes must be well secured, but they have no state, and can therefore be run on a completely read-only system. GÉANT CT log service differs in design when compared with CT solution from Google [https://github.com/google/certificate-transparency]. GÉANT CT log solution architecture consists of several simple components with well-defined interfaces (APIs). This architecture enables more controlled and easier to develop architecture, as each component can evolve as needed, not necessarily making an imperative for the other components to change and thus contributing to the correctness, robustness and overall security of the solution. With such design, GÉANT CT log can be established as a multi-domain solution. In this way, individual components can be placed in different organisations/geographically distributed places and thus share the burden and increase availability and reliability of the service. In addition, before GÉANT involvement, there were no scalable open-source solutions, and even though the situation is changing lately, multi-domain solution is provided only by GÉANT. The technology infrastructure used to provide the CT log service consists of free and open source software developed in-house and available here [https://www.ct.nordu.net/]. It is run on Unix-based systems capable of hosting Erlang virtual machines (VMs) and executing Python code. 7

4 Operations Operations of the CT log service are defined from the fit-for-purpose perspective and supported through the underlying technology to ensure its fit-for-use aspect. It also requires establishment of the supporting infrastructure, as well as the definition of operations and support teams, service policies, and the service metrics according to which the service will be evaluated and its success assessed. The operational aspects described in this section form part of the service definition and will be put in place in Period 2. 4.1 Supporting Infrastructure In addition to the architecture of the Certificate Transparency log server described in Section 3, the service is supported by the following components: Systems and service operations framework for service deployment and orchestration. Monitoring system for checking the health of systems and services and raising alarms. Hardware security module (HSM) infrastructure for keeping sensitive keys off general-purpose computers. Issue-tracking system for operational issues. All of these components will be established, validated and tested before the service transitions into production. 4.2 Operations and Support Teams There are three teams that support the GÉANT CT log service: Operations team, which takes care of the service in production, its central and distributed components, and manages and maintains the installed infrastructure as well as providing support for the users. The team s focus is existing users and installations. It will be reachable at ct-ops@lists.geant.org. Business development and service management team, which tracks the usage of the established service, gathers feedback and input from the user groups and actively takes part in the future-service roadmaps. The team s focus is potential and new users. It will be available at ct-team@lists.geant.org. 8

Operations CT developers team, which translates the input from the operations, business development and service management teams into future software and service versions. The team will be reachable at ct-dev@lists.geant.org, primarily for technical and implementation-specific topics. 4.3 Policies The Certificate Transparency log service, as explained in Section 2.2, is open to all web browser users, domain owners, browser vendors and/or CAs to submit certificates and/or query, monitor or audit existing certificates in the log. Additional support to any of the users e.g. how to use the service and how to get the most benefit out of it, and/or how to participate in the GÉANT CT log service is primarily offered to the GÉANT community. Usage policies and expectations exist between CAs and log providers (e.g. fast access to a log), or between browser vendors and log providers (e.g. Google s expectation of at least 99% availability, as measured by Google). In addition to this, the log is required to sign and publish a new tree head at least once every 24 hours. In practice, a new tree head should be published much more often, typically several times per hour. Such known requirements are being taken into consideration in the design of the operational and production service. 4.4 Metrics Availability is a key metric for measuring the success of a CT log service. Availability is actively being measured by a monitoring system. The monitoring system constantly submits test certificates to the log server and queries the server in order to establish confidence in log consistency and response times. Target availability is 99%. Other service metrics, such as the number of certificates in the log, growth in log size and number of read or write requests can also be measured to assess the load on the infrastructure, but cannot be considered as service performance indicators as they do not fall within the area of influence of the CT development or operations team. 9

5 Roadmap During Period 2 of GN4-2, the Certificate Transparency log service is scheduled to pass the pilot gate (as defined by GÉANT s product lifecycle management (PLM) process) and enter the service transition lifecycle phase in which the production infrastructure will be prepared with clean installations of all components, validated and tested from the functionality, performance and security perspective. The service is planned to be ready for production in spring 2018. The CT software will eventually have to be updated to reflect the changes in the protocol as a result of the standardisation efforts in IETF (e.g. work on [RFC6962-bis]). The software will also have to be continuously updated with security fixes. The major planned software releases will focus on documentation (1.0, 2018 Q1), performance (1.1, 2018 Q2) and the new protocol mentioned in the previous paragraph (2.0, 2018). In parallel with the preparations for production, the strategy and planning phase will start for future versions of CT. 10

6 Conclusions Development of the GÉANT Certificate Transparency log service is a continuation of work by SUNET/NORDUnet. The service should transition into production during GN4-2 Period 2. Based on IETF standards, it enables discovery of misissued certificates. By providing transparency of all issued certificates through the log, the CT log service enables monitoring and audit of the certificates issued for a domain. The service delivers clear trust and security benefits for its user community and for CT, the web space and the Internet as a whole. The GÉANT Certificate Transparency log service has three main aspects: installation of the CT log server, and providing two types of support to users: in using the service and/or in participating in the GÉANT CT log service by running a service architecture component in their own domain. The primary GÉANT CT log service users are domain owners, certification authorities and web users. The operations and support framework is designed primarily to support the GÉANT community in using the service and/or providing a similar CT log service in their domains. However, use of the CT log service is open to all CT users. The service is planned for production in spring 2018, based on the infrastructure, policies, metrics and operational and support teams described in this document. 11

References [catlfish] [RFC6962] https://www.ct.nordu.net/ B. Laurie, A. Langley, E. Kasper, IETF RFC 6962: Certificate Transparency, June 2013 https://tools.ietf.org/html/rfc6962 Glossary CT CA HSM HTTPS IETF JRA JRA2 JRA2 T6 NOC NREN PLM R&E RFC SCT STH VM Certificate Transparency Certification Authorities Hardware Security Module Hyper Text Transfer Protocol Secure Internet Engineering Task Force Joint Research Authority Network s Development JRA2 Task 6, Network Security Network Operations Centre National Research and Education Network Product Lifecycle Management Research and Education Request for Comments Signed Certificate Timestamp Signed Tree Head Virtual Machine 12