Encryption of Traffic

Transcription

1 Encryption of Traffic White Paper Version 1.1 Date:

2 Foreword On the initiative of some German automotive manufacturers work has started on a series of white papers on the subject of security. The first two documents have already been prepared. They are: an introductory document entitled Security that introduces the reader to the topic of protecting confidentiality during exchange ; a white paper entitled Encryption of Traffic describing pragmatic basic security using encryption, which is as transparent as possible for users. Two additional white papers, Encryption Using End-to-End Encryption and Mail Transfer Agents and Certificate and Trust Management - requirements for certificates and trust relationships are currently being prepared. The documents drawn up so far give the automotive industry an orientation based on existing technical approaches. Important elements here are userfriendliness and the application of the industry s standard confidentiality levels and measures derived from them. The VDA recommends its members to use the documents already prepared for orientation, and to implement the measures they describe in their companies. V E R S I O N 1. 1 P A G E 2

3 Contents Encryption of Traffic... 1 White Paper... 1 Foreword... 2 Contents... 3 Introduction... 4 Motivation... 4 Assumption... 4 Risks... 4 Measures... 4 Approaches to securing the transport route... 5 Encryption using tunneling... 5 Encryption of the transfer protocol... 5 Approaches and standards... 6 STARTTLS... 7 IPsec VPN... 7 Combining STARTTLS and IPsec VPN... 7 Requirements for use and approaches to realization... 8 Minimum requirements... 8 General requirements... 8 Mandatory requirements... 8 Other requirements... 9 Weaknesses / remaining risks and dangers... 9 Annex TCP/IP reference protocol Annex List of authors PAGE 3 V E R S I O N 1. 1

4 Introduction Motivation In the main document Security [W1], transport encryption is introduced as a measure for protecting the confidentiality of an message. Below we describe the organizational and technical implementation of this type of measure. Assumption It is assumed that transmission is sufficiently well protected in the firm s internal networks. This paper examines the task of securing transmission between the transport systems of corporate networks. Sender Empfänger Internet Figure 1: Insecure transmission Legenden: Recipient Risks Generally no great technical effort is required to copy and evaluate the contents of data traffic running between two transfer agents (MTAs) at the transport level, since this traffic is transmitted as clear text without any additional security mechanisms. Measures Two options for tackling this problem are encryption of the channel for transporting the s, and encryption of the s themselves. The latter is V E R S I O N 1. 1 P A G E 4

5 described in more detail in the document [W2]. Below we will only go into detail on encryption at the level of transport (MTAs) between the domains. Approaches to securing the transport route Encryption using tunneling In this case protection of an during transmission is based on encryption of the transport route, that is, on the transport layer (see Annex TCP/IP reference model). Examples of this would be: using a tunnel connection via the internet or via private network connections between two partners, such as an IPsec VPN connection; secure transmission within a dedicated network, such as ENX. Assumption: the MTAs internal network connection to the router is made secure. Sender Empfänger Tunnel Internet Figure 2: transmission using VPN tunneling to send data across the network (router, MTA) Legenden: Recipient Encryption of the transfer protocol As an alternative to tunneling, encryption may be applied using an transfer protocol in the application layer. Here again, it is not individual s themselves that are encrypted, but the exchange of data between the transmitting MTAs. Examples of this would be: Encryption of data exchange within the SMTP protocol using Transport Layer Security (SMTP/TLS as SMTPS on port 465). PAGE 5 V E R S I O N 1. 1

6 The authors regard SMTPS as not practicable and it is no longer applied, since RFC 2595 already advises against SMTPS with dedicated ports. Encryption of data exchange within the SMTP protocol using Transport Layer Security (SMTP using STARTTLS, called STARTTLS below). STARTTLS is described in RFC 3207 and has established itself on the market. The connection with the other party is initially established in the clear. Then, if STARTTLS is also supported by the other party, the is transferred with protection in the current session via the same port. Sender (MTA) Empfänger (MTA) TLS, fallweise Internet Figure 3: transmission with SMTP using STARTTLS (MTA to MTA) Legenden: Recipient case-by-case Approaches and standards In the future all s exchanged with partners should be sent using secure transmission. In a first step, the objective is to define a procedure that: all members can implement simply, pragmatically and swiftly, requires no central organizational control, takes existing procedures into consideration, can continue to be used with future extensions, provides sufficient security mechanisms. The implementation of agreements on the types of solutions described, such as the TLS approach or using VPN in traffic between the communication partners, is defined in specific regulations. V E R S I O N 1. 1 P A G E 6

7 STARTTLS Today a large number of common MTAs support SMTP with TLS as an encryption protocol (STARTTLS) for communicating with other MTAs. A manageable amount of technical and financial input is needed to implement STARTTLS, without the need for central verification control. In the future, every MTA that is accessible from the internet should support this protocol. This does not apply to MTAs that are not accessible from the internet, but which operate exclusively within an existing, secured network. Two security levels are distinguished. STARTTLS-setting with the option of sending unencrypted if STARTTLS is not available at the recipient (opportunistic mode, opportunistic TLS). mandatory use of STARTTLS (secure high-grade ciphers mandatory mode, mandatory TLS). Assumption: in this approach the firm s internal network begins at the MTA. IPsec VPN With IPsec VPN the traffic is encrypted by routers between the MTAs on the network layer. This technology is already used successfully by various companies in the automotive industry especially on the basis of ENX. ENX (European Network Exchange) is a special VPN installation. ENX is a paid-for communication network for the European automotive industry; it is a separate network that is accessible only to the members, who pay for the service. The connections within ENX are secured using IPsec. If the MTAs involved use only these secure paths for receiving and sending e- mails, this encryption is regarded as sufficient. Assumption: in this approach the firm s internal network begins at the VPN router. Combining STARTTLS and IPsec VPN It is technically possible to combine STARTTLS and IPsec VPN, but it is not regarded as necessary. PAGE 7 V E R S I O N 1. 1

8 Requirements for use and approaches to realization Minimum requirements The confidentiality levels described in the main document ( Security ) form the basis for the requirements listed below. General requirements Use of STARTTLS in opportunistic mode (opportunistic TLS) for general e- mail traffic on all MTAs that are accessible from the internet. All participating organizations / companies should use certificates in accordance with the X.509 standard. Use of cryptographic procedures currently regarded as sufficiently secure according to the document Kryptographische Verfahren: Empfehlungen und Schlüssellängen ( Cryptographic procedures: recommendations and key lengths, available in German at: and/or the corresponding recommendation from the NIST (in English, see also [W1] under References. Mandatory requirements Mandatory requirements apply to transmission of s classified as confidential, if they are not sufficiently protected by other measures. Mandatory requirements serve to fulfill legal or contractual obligations to protect s between the communicating parties, if these obligations are not satisfied by other means. Use of STARTTLS in secure high-grade ciphers mandatory mode (mandatory TLS) for confidential traffic on all MTAs accessible from the internet. logging and/or monitoring should be used to verify that communication is taking place in compliance with the requirements. All organizations and companies involved should use certificates in accordance with the X.509 standard, which satisfy the requirements defined for this application in the document [W4]. Use of cryptographic procedures currently regarded as sufficiently secure according to the document Kryptographische Verfahren: Empfehlungen und Schlüssellängen ( Cryptographic procedures: recommendations and key lengths, available in German at: and/or the corresponding recommendation from the NIST (in English, see also [W1] under References. V E R S I O N 1. 1 P A G E 8

9 Other requirements The extent to which certificates are supported, which do not originate from the Public Key Infrastructure (PKI), must be examined in each separate case, because verification of these certificates is problematic without a central verification control. A bilateral trust status can be set up manually until a central service is established. Weaknesses / remaining risks and dangers Deliberate manipulation (e.g. by a disgruntled employee) cannot be avoided by encryption. In general there is no check that the content is factually correct. This risk can be tackled only with other measures (e.g. internal security guidelines). It is not possible to prevent the faking of sender addresses without taking additional technical or organizational action. Absence of measures for ensuring data integrity could be tackled, for example, with additional sender verification or the exclusive use of the tunneling procedures as described above. Another known procedure for verifying the sender is authentication of the sender using DKIM. However, up to now the procedure has not been used on a wide scale and it offers only limited protection. Security is assumed as a result of equating the company with one of its domains: if, for example, mandatory STARTTLS applies to one domain belonging to a company, this does not necessarily apply to all other domains belonging to the same company (e.g. firmdomain.com and firmdomain.de). Configuration changes at the sender or recipient, e.g. a change in an IP address, and changes in certificates, must feed into the change and configuration management on both sides, because otherwise encrypted transmission can no longer be guaranteed. PAGE 9 V E R S I O N 1. 1

10 Annex TCP/IP reference protocol TCP / IP layer Application layer Transport layer Network layer Data link layer Examples HTTP, FTP, SMTP, TCP, UDP, IPv4, IPv6 Ethernet, Token Ring The layers of the TCP/IP reference model in detail: Application layer: the application layer comprises all the protocols that cooperate with application programs and use the network infrastructure for exchanging application-specific data. Transport layer: the transport layer creates an end-to-end connection. The most important protocol in this layer is the Transmission Control Protocol (TCP), which creates connections between two network participants for reliable exchange of data flows. Network layer: the network layer is responsible for forwarding packets and for routing. Point-to-point connections are created on this layer and the layers below. The task of this layer is to identify the next MTA for a received packet and to send the packet to that destination. At the heart of this layer is the Internet Protocol (IP) that provides a packet delivery service. Data link layer: the data link layer is specified in the TCP/IP reference model, but it does not contain any protocols belonging to the TCP/IP family. Instead, it should be understood as a placeholder for various technologies for transferring data from point to point. The internet protocols were developed to combine different subnetworks. The host-to-network layer can therefore be filled with protocols such as Ethernet, FDDI, PPP (point-to-point protocol) or (WLAN). V E R S I O N 1. 1 P A G E 10

11 Annex For specifications, references and the glossary, please see the main document [W1] with the same or a later version number. List of authors Name Company address Frölich, Jens AUDI AG jens.froelich@audi.de Ionescu, Michael Porsche-Information- Kommunikation-Services GmbH michael.ionescu@porsche.de Klingel, Jan-Arendt BMW Group jan-arendt.klingel@bmw.de Kohn, Stefan Volkswagen AG stefan.kohn@volkswagen.de Scherr, Carsten Daimler AG carsten.scherr@daimler.com Document and version history: Version Date Status, remarks Final version Revised by working group PAGE 11 V E R S I O N 1. 1