80.3.6 Internet of Things and Industry 4.0
It is predicted that until 2020 there will be up to 30 billion devices [6] connected to the Internet. To ensure a minimum level of security every device has to be authenticated to be able to automatically access data and resources. Beside the authentication of the device to a network and other devices, the authentication by a user against IoT devices will be one of the most authentication scenarios in the near future. Because of the amount of authentications it will be necessary that the authentication process is easy, fast and secure.
Since IoT connects the real and digital world IT security and thereby strong authentication becomes an important part to ensure safety.
The DDOS attacks with the “Mirai botnet” [7] in October 2016 shows, that the use of password‐based authentication is insufficient.
To solve the IoT password problem the devices can be equipped with digital certificates and digital attribute certificates. With that combination the IoT devices can be connected to the XignQR infrastructure. The devices are now able to authenticate them self against other devices connected to the XignQR infrastructure in the same way a user will authenticate its self by using the smartphone. The authentication process is completely the same, only the smartphone is replaces by the IoT device. The entry point for the devices authentication can be a QR Code, like it is in the users authentication process, but also other authentication trigger can be included, for example an alert of an temperature sensor.
The identification of a device with a QR Code or NFC trigger helps to gain maximum flexibility. If a user wants to interact with an IoT device, it can use XignQR to authenticate itself in the same way the user authenticates itself against a website. On the one hand XignQR implements a high level of security by the substitution of the insecure password based authentication, for example the mentioned “Mirai Botnet” attack could not be realized with the use of XignQR. And on the other hand a user can easily interact with the IoT devices [8], also in an environment where the implementation of keyboards or other hardware is expensive or no possible, for example in the urban environment of “smart cities”.
The digitalization of the production industry leads to many different and complex scenarios. It starts with the connection of different departments within a company and ends with the interconnection of production machines and the automation of production and business processes, based on decisions invoked by a machine signal. Therefor it is inalienable that process and data is authenticated.
But even the existing problems in the industry environment can be solved with XignQR. For example a massive problem is the access to production machines for maintaining.
Today the physical access to production machines is still done with a mechanical key and lock. To access the terminal at a production machine a strong password up to twenty and more characters is needed.
This combination is highly insecure and needs a lot of administration. For example, a maintenance worker needs to get the key to gain physical access and the strong password. The passwords are usually written down, because nobody is able to remember these types of passwords. Sometimes the passwords are directly noted at the terminal of the production machine.
The use of strong and flexible certificate based authentication is a solution the addresses all the mentioned problems.
Using XignQR improves the user experience for the administration and for the maintenance worker. An administrator can grant physical access for a defined timeframe to an explicit user or user group. And at the terminal there is no need for passwords, thereby no passwords can be written down at the terminal. Since the system can be remotely managed, also authorization processes can be implemented due to the substitution of the password.
80.4 The Authentication Process
The Fig. 80.5 shows the process of authentication with XignQR. Authentication is achieved through the interaction of the three main components of the system, the Xign Manager, the XignApp on the user’s smartphone and the service provider. The Xign Manager builds the core of the system. It mediates between the XignApp and the service provider to authenticate users. Users are authenticated using the Xign App, while the Xign Manager delivers QR codes, authentication events and user information to the service provider, who then grants or denies access to his services on behalf of the received information. An authentication is initiated by the service provider that sends an authentication request to the Xign Manager. The Xign Manager responds with a QR code that has to be displayed to the user. The user scans the QR code using his Xign App to authenticate against the Xign Manager leveraging a cryptographic challenge‐response‐mechanism. The result of the challenge‐response scheme is transferred back to the service provider afterwards. The result message contains the status of the corresponding authentication process and a token that is used to request the user information from the Xign Manager.
Fig. 80.5Authentication process
References
1.
M. Hertlein, P. Manaras und N. Pohlmann, “Bring Your Own Devide For Authentication (BYOD4A),” in In Proceedings of the ISSE 2015 – Securing Electronic Business Processes – Highlights of the Information Security Solutions Europe 20151 Conference, Wiesbaden, Springer Vieweg Verlag, 2015.
2.
C. Okyle, “Password Statistics: The Bad, the Worse and the Ugly (Infographic),” [Online]. Available: http://www.entrepreneur.com/article/246902 [Accessed 17 August 2016].
3.
S. Goswami, S. Misra und M. Mukesh, “A replay attack resilient system for PKI based authentication in challenge-response mode for online application,” 3rd International Conference on Eco-friendly Computation and Communication Systems, 2014.
4.
E. Union, “REGULATION (EU) No 910/2014 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL,” [Online]. Available: http://eur-lex.europa.eu/legal-content/EN/HTML/?uri=CELEX:32014R0910 [Accessed 17 August 2016].
5.
M. Schröder und M. Morgner, “eID mit abgeleiteten Idenititäten,” in DuD Datenschutz und Datensicherheit 8-2013, Heidelberg, Springer, 2006.
6.
H. Bauer, M. Patel und J. Veira, “The Internet of Things: Sizing up the opportunity,” [Online]. Available: http://www.mckinsey.com/industries/high-tech/our-insights/the-internet-of-things-sizing-up-the-opportunity. [Accessed 28 October 2016].
7.
S. Cobb, “10 things to know about the October 21 IoT DDos attacks,” [Online]. Available: http://www.welivesecurity.com/2016/10/24/10-things-know-october-21-iot-ddos-attacks/. [Accessed 28 October 2016].
8.
M. Cagnazzo, M. Hertlein und N. Pohlmann, “Information and Software Technologies: An Usable Application of Authentication, Communication and Access Management in the Internet of Things,” in 22nd International Conference, ICIST 2016, Druskininkai, Lithuania, Springer International Publishing, 2016, pp. 722–731.
© Springer-Verlag GmbH Germany 2018
Claudia Linnhoff-Popien, Ralf Schneider and Michael Zaddach (eds.)Digital Marketplaces Unleashedhttps://doi.org/10.1007/978-3-662-49275-8_81
81. Implications of Vulnerable Internet Infrastructure
Haya Shulman1
(1)Fraunhofer Institute for Secure Information Technology SIT, Darmstadt, Germany
Haya Shulman
Email: [email protected]
81.1 Introduction
The last decade was marked with revelations on cyber espionage, monitoring and censorship by governments, devastating Denial of Service (DoS) and malware attacks launched by terror or military organizations, credentials and identity theft, robbery of sensitive and private information by cyber criminals, and more. The attacks target individuals, enterprises, governments, critical and civil infrastructures.
The surge of cyber attacks
resulted in increased awareness to the need to protect the clients and services. As a result, during the last decade multiple defences were put forth for securing the communication between clients and services, most notably with the use of SSL/TLS [RFC5246] for email, web servers and instant messaging. Indeed, a recent study (by heise.de) reported that encrypted traffic in the Internet reached 50%.
Intuitively it seems that protecting the communication to services should suffice to prevent attacks against clients. In particular, if the communication, say between a user and its bank, is encrypted and authenticated, then the attacker should not be able to snoop on the exchanged messages, nor modify them. In this chapter we consider the following question: How effective are defences for clients and services in the current Internet?
We answer this question in two steps. First, we review the security of the Internet’s fundamental building blocks, focusing on the inter‐domain routing with Border Gateway Protocol (BGP) [RFC1105], naming with Domain Name System (DNS) [RFC1035], and Small Office/Home Office routers [RFC3022]. As we report, not only do these critical systems have a long history of attacks, but they are also still susceptible to attacks on a daily basis. Many attacks are detected too late after a significant damage is inflicted, while a large number of others are not identified at all. Although defences exist, they mostly are not deployed. Worse, we show that deployed countermeasures are often not effective since many deployments of security are incorrect, leading to illusion of security.
Then, in the second step, we review a number of widely used security mechanisms, including password recovery on popular websites, anti‐spam defences and encryption with SSL/TLS. We show that vulnerabilities in fundamental systems of the Internet render defences for clients and services exposed to attacks.
Our analysis and conclusions apply also to other fundamental Internet systems, such as Network Time Protocol (NTP), Internet telephony, cloud platforms and others.
Organization
In Sect. 81.2 we present selected Internet Infrastructure systems, discuss their vulnerabilities and attacks against them, and provide our measurements on the state of adoption of security mechanisms. In Sect. 81.3 we list popular defences and show that they can be foiled given the insecurity of Internet foundations. We conclude in Sect. 81.4.
81.2 Fundamental Internet Infrastructure Systems
In this Section we review Domain Name System (DNS), Border Gateway Protocol (BGP) and SOHO routers. BGP computes the path that the packets should take between communicating parties in the Internet, DNS provides an address of the destination while SOHO routers protect the networks of clients and enterprises.
DNS and BGP were not designed with security in mind, and both have experienced a long history of attacks. To mitigate the problems, security mechanisms were designed and standardized for both of them more than two decades ago. However, most of the networks and systems are still running the basic protocols without the security protection. Hence they are susceptible to frequent attacks. Even when security mechanisms are deployed, this is often done incorrectly, not offering any security benefits. The same applies to SOHO routers: although vulnerabilities are long known, many networks are vulnerable to attacks which allow attackers to take over the routers and networks. In this section we review the vulnerabilities, provide example attacks and report on our measurement evaluations showing that defences are mostly not deployed or deployed incorrectly.
81.2.1 Domain Name System (DNS)
Domain Name System (DNS), [RFC1034, RFC1035], plays a key role in the Internet: it translates domain names to IP addresses and provides a platform for distribution of security mechanisms, such as digital certificates [RFC6698], anti‐spam defences [RFC7208]. For instance, when clients access websites the first step is a request to a DNS resolver asking to lookup an IP address for the desired domain name, say www.amazon.com. Using the IP address, the client can then access the service.
The correctness and availability of DNS are critical to the security and stability of the Internet. However, its significance also made it a target of attacks, most notably, DNS cache poisoning, [1–5].
DNS Cache Poisoning
In the course of a DNS cache poisoning attack the attacker provides spoofed values in DNS responses. In order for responses to be accepted by the victim, the attacker needs to match several fields, which are checked by the recipient’s DNS software. These fields include the port from which the request was sent and a DNS transaction identifier (TXID). As a result, the victims are redirected to incorrect and attacker controlled hosts. DNS cache poisoning attack is initiated when a client sends a DNS request to the DNS server asking to look up a desired domain. If the attacker responds of a real DNS server instead, and the client accepts the response with malicious DNS records, it will have the IP address for an incorrect (malicious) machine, instead of a real one. If the client uses the malicious values it received from the attacker it is exposed to credentials theft, malware distribution, censorship and more. For instance, the attackers can utilize DNS cache poisoning to hijack emails to victim email servers in order to steal victims’ credentials to sensitive services, such as ebay.com or amazon.com, by using their password recovery procedures. As we show in Sect. 81.3.1, the attackers can then hijack the victims’ credentials that are sent by these services, since the credentials are sent to the incorrect email IP address provided by the attacker in poisoned DNS records.
DNS cache poisoning attacks are known to be practiced by governments, e. g., China for censorship, [6], USA with the QUANTUMDNS program [7] (see Fig. 81.1), as well as by cyber criminals. Research works also performed measurements of spoofed DNS responses in the Internet [8–11].
Fig. 81.1QUANTUMDNS program
Defences Against Cache Poisoning
DNS cache poisoning is detrimental for the security and stability of the clients and services, yet cache poisoning attacks are often practiced by governments and cyber criminals. Due to the threat that cache poisoning attacks pose, multiple defences were proposed and standardized. Non cryptographic defences recommend randomizing values in the existing fields, such as in UDP and DNS headers, to make it difficult for the attacker to create a response with correct values. The most common defence is source port randomization and others, see [RFC5452]. Source port randomization makes the attack more difficult, since the attacker has to guess the port value in its malicious responses, so that it matches the value selected by the DNS resolver in its DNS request. Since the port is 16 bits long, the attacker can try multiple variations until a correct one is hit. In order to check how many systems adopted source port randomization we performed a large scale evaluation of port randomization in DNS resolvers in the Internet and found that 1% send DNS requests using static (fixed) source port and 17% use predictable ports, e. g., sequentially incrementing. These systems are trivially exposed to DNS cache poisoning attacks. In recent works [12, 13] we showed that some randomization algorithms, recommended and standardized in [RFC6056] are insecure. Hence also systems supporting these algorithms can be attacked.
Cryptographic defence with DNSSEC [RFC4033–RFC4035] recommends using digital signatures in order to authenticate the records in DNS responses. The receiver can then verify that the signatures over the records are correct. The security is guaranteed since only the domain owner is in possession of the secret signing key that produced the signatures. The attacker does not have the key and hence cannot generate signatures instead of the domain owner.
Although proposed in 1997, DNSSEC still is not widely deployed. One of the factors impeding deployment is the requirement for significant changes to the DNS infrastructure as well as to DNS protocol. In particular, the DNS server should serve signed records in DNS responses, which should then be validated on the clien
t side by the DNS resolvers. The resolvers should accept and cache only the records with correct signatures. Unfortunately, studies show that less than 3% of DNS resolvers validate DNSSEC signatures [14]. Furthermore, our recent measurement evaluation [15] of Top Level Domains (TLDs) and 1 M‐top ranked domains on www.alexa.com (Second Level Domains (SLDs)), shows that 90% of TLDs and only a meagre fraction of 1.66% of the domains on Alexa list are signed. Since the users are typically interested in accessing domains on second level such as google.com, protecting the SLDs with DNSSEC is very important. Although very few domains are signed, our experimental evaluation shows that most of those are still not well protected. The problems are manifested in generation and deployment of cryptographic material. The first issue is related to validating keys. Specifically, in 0.89% TLDs and 19.46% Alexa domains it is not possible to establish validity of DNSSEC keys and as a result, the signed records in these domains cannot be validated. Another issue is related to the usage of short (insecure) keys. We measured the key sizes in use by the different variations of RSA algorithms. The results, plotted in Fig. 81.2, indicate that a large fraction of domains use short DNSSEC keys. In particular, almost 1.4 M keys are below 1024 bits and 10 K keys are 512 bits long [16]. showed that factoring 512 bit keys on a cloud is a practical task, hence these domains are exposed to DNS cache poisoning attacks.
Fig. 81.2RSA keys’ sizes
Digital Marketplaces Unleashed Page 123