Refine
Document Type
- Conference Proceeding (19)
- Article (reviewed) (2)
- Report (1)
Conference Type
- Konferenzartikel (19)
Is part of the Bibliography
- yes (22) (remove)
Keywords
- Eingebettetes System (3)
- Automation (1)
- Design (1)
- Dissens (1)
- Flugdatenregistriergerät (1)
- Gebäudeleittechnik (1)
- IEC/IEEE 60802 security (1)
- Industrie 4.0 (1)
- Intelligentes Stromnetz (1)
- Kommunikation (1)
Institute
Open Access
- Closed Access (12)
- Closed (5)
- Open Access (3)
- Bronze (1)
- Diamond (1)
The CAN bus still is an important fieldbus in various domains, e.g. for in-car communication or automation applications. To counter security threats and concerns in such scenarios we design, implement, and evaluate the use of an end-to-end security concept based on the Transport Layer Security protocol. It is used to establish authenticated, integrity-checked, and confidential communication channels between field devices connected via CAN. Our performance measurements show that it is possible to use TLS at least for non time-critical applications, as well as for generic embedded networks.
Security in IT systems, particularly in embedded devices like Cyber Physical Systems (CPSs), has become an important matter of concern as it is the prerequisite for ensuring privacy and safety. Among a multitude of existing security measures, the Transport Layer Security (TLS) protocol family offers mature and standardized means for establishing secure communication channels over insecure transport media. In the context of classical IT infrastructure, its security with regard to protocol and implementation attacks has been subject to extensive research. As TLS protocols find their way into embedded environments, we consider the security and robustness of implementations of these protocols specifically in the light of the peculiarities of embedded systems. We present an approach for systematically checking the security and robustness of such implementations using fuzzing techniques and differential testing. In spite of its origin in testing TLS implementations we expect our approach to likewise be applicable to implementations of other cryptographic protocols with moderate efforts.
The Transport Layer Security (TLS) protocol is a cornerstone of secure network communication, not only for online banking, e-commerce, and social media, but also for industrial communication and cyber-physical systems. Unfortunately, implementing TLS correctly is very challenging, as becomes evident by considering the high frequency of bugfixes filed for many TLS implementations. Given the high significance of TLS, advancing the quality of implementations is a sustained pursuit. We strive to support these efforts by presenting a novel, response-distribution guided fuzzing algorithm for differential testing of black-box TLS implementations. Our algorithm generates highly diverse and mostly-valid TLS stimulation messages, which evoke more behavioral discrepancies in TLS server implementations than other algorithms. We evaluate our algorithm using 37 different TLS implementations and discuss―by means of a case study―how the resulting data allows to assess and improve not only implementations of TLS but also to identify underspecified corner cases. We introduce suspiciousness as a per-implementation metric of anomalous implementation behavior and find that more recent or bug-fixed implementations tend to have a lower suspiciousness score. Our contribution is complementary to existing tools and approaches in the area, and can help reveal implementation flaws and avoid regression. While being presented for TLS, we expect our algorithm's guidance scheme to be applicable and useful also in other contexts. Source code and data is made available for fellow researchers in order to stimulate discussions and invite others to benefit from and advance our work.
Exploiting Dissent: Towards Fuzzing-based Differential Black Box Testing of TLS Implementations
(2017)
The Transport Layer Security (TLS) protocol is one of the most widely used security protocols on the internet. Yet do implementations of TLS keep on suffering from bugs and security vulnerabilities. In large part is this due to the protocol's complexity which makes implementing and testing TLS notoriously difficult. In this paper, we present our work on using differential testing as effective means to detect issues in black-box implementations of the TLS handshake protocol. We introduce a novel fuzzing algorithm for generating large and diverse corpuses of mostly-valid TLS handshake messages. Stimulating TLS servers when expecting a ClientHello message, we find messages generated with our algorithm to induce more response discrepancies and to achieve a higher code coverage than those generated with American Fuzzy Lop, TLS-Attacker, or NEZHA. In particular, we apply our approach to OpenssL, BoringSSL, WolfSSL, mbedTLS, and MatrixSSL, and find several real implementation bugs; among them a serious vulnerability in MatrixSSL 3.8.4. Besides do our findings point to imprecision in the TLS specification. We see our approach as present in this paper as the first step towards fully interactive differential testing of black-box TLS protocol implementations. Our software tools are publicly available as open source projects.
PROFINET Security: A Look on Selected Concepts for Secure Communication in the Automation Domain
(2023)
We provide a brief overview of the cryptographic security extensions for PROFINET, as defined and specified by PROFIBUS & PROFINET International (PI). These come in three hierarchically defined Security Classes, called Security Class 1,2 and 3. Security Class 1 provides basic security improvements with moderate implementation impact on PROFINET components. Security Classes 2 and 3, in contrast, introduce an integrated cryptographic protection of PROFINET communication. We first highlight and discuss the security features that the PROFINET specification offers for future PROFINET products. Then, as our main focus, we take a closer look at some of the technical challenges that were faced during the conceptualization and design of Security Class 2 and 3 features. In particular, we elaborate on how secure application relations between PROFINET components are established and how a disruption-free availability of a secure communication channel is guaranteed despite the need to refresh cryptographic keys regularly. The authors are members of the PI Working Group CB/PG10 Security.
The Datagram Transport Layer Security (DTLS) protocol has been designed to provide end-to-end security over unreliable communication links. Where its connection establishment is concerned, DTLS copes with potential loss of protocol messages by implementing its own loss detection and retransmission scheme. However, the default scheme turns out to be suboptimal for links with high transmission error rates and low data rates, such as wireless links in electromagnetically harsh industrial environments. Therefore, in this paper, as a first step we provide an analysis of the standard DTLS handshake's performance under such adverse transmission conditions. Our studies are based on simulations that model message loss as the result of bit transmission errors. We consider several handshake variants, including endpoint authentication via pre-shared keys or certificates. As a second step, we propose and evaluate modifications to the way message loss is dealt with during the handshake, making DTLS deployable in situations which are prohibitive for default DTLS.
It seems to be a widespread impression that the use of strong cryptography inevitably imposes a prohibitive burden on industrial communication systems, at least inasmuch as real-time requirements in cyclic fieldbus communications are concerned. AES-GCM is a leading cryptographic algorithm for authenticated encryption, which protects data against disclosure and manipulations. We study the use of both hardware and software-based implementations of AES-GCM. By simulations as well as measurements on an FPGA-based prototype setup we gain and substantiate an important insight: for devices with a 100 Mbps full-duplex link, a single low-footprint AES-GCM hardware engine can deterministically cope with the worst-case computational load, i.e., even if the device maintains a maximum number of cyclic communication relations with individual cryptographic keys. Our results show that hardware support for AES-GCM in industrial fieldbus components may actually be very lightweight.
Die industrielle Kommunikation war früher von relativ eingeschränkten, geschlossenen Feldbussystemen geprägt. Mit der zunehmenden Öffnung von Automatisierungsnetzen durch die horizontale und vertikale Integration in Produktionsanlagen entstehen gefährliche Angriffsflächen, die zum Diebstahl von Produktionsgeheimnissen, der Manipulation oder dem kompletten Lahmlegen der Produktionsprozesse führen können. Hieraus ergeben sich grundlegend neue Anforderung an die Datensicherheit, denen mit innovativen Lösungsansätzen begegnet werden muss.
Ziel des Forschungsvorhabens „SecureField“ war es, die Umsetzbarkeit und Anwendbarkeit des Ansatzes „(D)TLS-over-Anything“ zu untersuchen und nachzuweisen, sowie einen Werkzeugkasten zur Definition und Implementierung entsprechender Sicherheitslösungen vorzubereiten. Als langjährig etablierter Standard im IT-Umfeld stellte sich das (Datagram) Transport Layer Security ((D)TLS) Protokoll in Kombination mit einer industrie- bzw. automatisierungskompatiblen Public-Key-Infrastruktur (PKI) als äußerst vielversprechende Möglichkeit dar, Datensicherheit auch im OT-Umfeld zu erzielen. Hierbei sollten insbesondere KMU adressiert werden, für welche eigene Entwicklungsarbeiten in diesem Umfeld häufig zu aufwändig und technisch sowie wirtschaftlich zu riskant sind.
Mit „SecureField“ konnten Ergebnisse auf mehreren Ebenen erzielt werden. Zunächst konnte im Projektverlauf ein umfassendes und generisches Konzept zur Ende-zu-Ende-Absicherung von Kommunikationspfaden und -protokollen im industriellen Umfeld erarbeitet werden. Dieses Konzept besteht aus einem generischen Kommunikationsmodell sowie aus einem generischen Authentifikationsmodell.