Internet security for mobile computing

Mobile devices are now the most dominant computer platform. Every time a mobile web application accesses the internet, the end user’s data is susceptible to malicious attacks. For instance, when paying a bill at a store with NFC mobile payment, navigating through a city operating GPS on a smartphone, or dictating the temperature at a household with a home automation device. These activities seem routine, yet, when vulnerabilities are present they can leave holes for hackers to access bank accounts, pinpoint a user’s recent location, or tell when someone is not at home. The awareness of the end user cannot be trusted. Device vendors and developers must provide safeguards. An ongoing issue is that the present security standards are outdated and were never envisioned with mobile devices in mind. It can be suggested that security is only idling the progress of mobile computing. Still, many application developers and IT professionals do not adopt security standards fast enough to keep up-to-date with known vulnerabilities. The main goals of the next generation of security standards, TLS, will provide developers with greater security efficiency and improved mobile throughput. These proposed capabilities of the TLS protocol will streamline mobile computing into the forefront of security practices. The analysis of this report demonstrates concepts on the direction mobile security, usability, and performance from a development standpoint.Electrical and Computer Engineerin

Efficient Implementation on Low-Cost SoC-FPGAs of TLSv1.2 Protocol with ECC_AES Support for Secure IoT Coordinators

Security management for IoT applications is a critical research field, especially when taking into account the performance variation over the very different IoT devices. In this paper, we present high-performance client/server coordinators on low-cost SoC-FPGA devices for secure IoT data collection. Security is ensured by using the Transport Layer Security (TLS) protocol based on the TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 cipher suite. The hardware architecture of the proposed coordinators is based on SW/HW co-design, implementing within the hardware accelerator core Elliptic Curve Scalar Multiplication (ECSM), which is the core operation of Elliptic Curve Cryptosystems (ECC). Meanwhile, the control of the overall TLS scheme is performed in software by an ARM Cortex-A9 microprocessor. In fact, the implementation of the ECC accelerator core around an ARM microprocessor allows not only the improvement of ECSM execution but also the performance enhancement of the overall cryptosystem. The integration of the ARM processor enables to exploit the possibility of embedded Linux features for high system flexibility. As a result, the proposed ECC accelerator requires limited area, with only 3395 LUTs on the Zynq device used to perform high-speed, 233-bit ECSMs in 413 µs, with a 50 MHz clock. Moreover, the generation of a 384-bit TLS handshake secret key between client and server coordinators requires 67.5 ms on a low cost Zynq 7Z007S device

Elliptic Curve Cryptography in Practice

In this paper, we perform a review of elliptic curve cryptography (ECC), as it is used in practice today, in order to reveal unique mistakes and vulnerabilities that arise in implementations of ECC. We study four popular protocols that make use of this type of public-key cryptography: Bitcoin, secure shell (SSH), transport layer security (TLS), and the Austrian e-ID card. We are pleased to observe that about 1 in 10 systems support ECC across the TLS and SSH protocols. However, we find that despite the high stakes of money, access and resources protected by ECC, implementations suffer from vulnerabilities similar to those that plague previous cryptographic systems

Practical realisation and elimination of an ECC-related software bug attack

We analyse and exploit implementation features in OpenSSL version 0.9.8g which permit an attack against ECDH-based functionality. The attack, although more general, can recover the entire (static) private key from an associated SSL server via $633$ adaptive queries when the NIST curve P-256 is used. One can view it as a software-oriented analogue of the bug attack concept due to Biham et al. and, consequently, as the first bug attack to be successfully applied against a real-world system. In addition to the attack and a posteriori countermeasures, we show that formal verification, while rarely used at present, is a viable means of detecting the features which the attack hinges on. Based on the security implications of the attack and the extra justification posed by the possibility of intentionally incorrect implementations in collaborative software development, we conclude that applying and extending the coverage of formal verification to augment existing test strategies for OpenSSL-like software should be deemed a worthwhile, long-term challenge.This work has been supported in part by EPSRC via grant EP/H001689/1 and by project SMART, funded by ENIAC Joint Undertaking (GA 120224)

An Internet-Wide Analysis of Diffie-Hellman Key Exchange and X.509 Certificates in TLS

Transport Layer Security (TLS) is a mature cryptographic protocol, but has flexibility during implementation which can introduce exploitable flaws. New vulnerabilities are routinely discovered that affect the security of TLS implementations. We discovered that discrete logarithm implementations have poor parameter validation, and we mathematically constructed a deniable backdoor to exploit this flaw in the finite field Diffie-Hellman key exchange. We described attack vectors an attacker could use to position this backdoor, and outlined a man-in-the-middle attack that exploits the backdoor to force Diffie-Hellman use during the TLS connection. We conducted an Internet-wide survey of ephemeral finite field Diffie-Hellman (DHE) across TLS and STARTTLS, finding hundreds of potentially backdoored DHE parameters and partially recovering the private DHE key in some cases. Disclosures were made to companies using these parameters, resulting in a public security advisory and discussions with the CTO of a billion-dollar company. We conducted a second Internet-wide survey investigating X.509 certificate name mismatch errors, finding approximately 70 million websites invalidated by these errors and additionally discovering over 1000 websites made inaccessible due to a combination of forced HTTPS and mismatch errors. We determined that name mismatch errors occur largely due to certificate mismanagement by web hosting and content delivery network companies. Further research into TLS implementations is necessary to encourage the use of more secure parameters

Post-Quantum TLS on Embedded Systems

We present our integration of post-quantum cryptography (PQC), more specifically of the post-quantum KEM scheme Kyber for key establishment and the post-quantum signature scheme SPHINCS$^+$, into the embedded TLS library mbed TLS. We measure the performance of these post-quantum primitives on four different embedded platforms with three different ARM processors and an Xtensa LX6 processor. Furthermore, we compare the performance of our experimental PQC cipher suite to a classical TLS variant using elliptic curve cryptography (ECC). Post-quantum key establishment and signature schemes have been either integrated into TLS or ported to embedded devices before. However, to the best of our knowledge, we are the first to combine TLS, post-quantum schemes, and embedded systems and to measure and evaluate the performance of post-quantum TLS on embedded platforms. Our results show that post-quantum key establishment with Kyber performs well in TLS on embedded devices compared to ECC variants. The use of SPHINCS$^+$ signatures comes with certain challenges in terms of signature size and signing time, which mainly affects the use of embedded systems as PQC-TLS server but does not necessarily prevent embedded systems to act as PQC-TLS clients

In search of CurveSwap: Measuring elliptic curve implementations in the wild

We survey elliptic curve implementations from several vantage points. We perform internet-wide scans for TLS on a large number of ports, as well as SSH and IPsec to measure elliptic curve support and implementation behaviors, and collect passive measurements of client curve support for TLS. We also perform active measurements to estimate server vulnerability to known attacks against elliptic curve implementations, including support for weak curves, invalid curve attacks, and curve twist attacks. We estimate that 0.77% of HTTPS hosts, 0.04% of SSH hosts, and 4.04% of IKEv2 hosts that support elliptic curves do not perform curve validity checks as specified in elliptic curve standards. We describe how such vulnerabilities could be used to construct an elliptic curve parameter downgrade attack called CurveSwap for TLS, and observe that there do not appear to be combinations of weak behaviors we examined enabling a feasible CurveSwap attack in the wild. We also analyze source code for elliptic curve implementations, and find that a number of libraries fail to perform point validation for JSON Web Encryption, and find a flaw in the Java and NSS multiplication algorithms