Biblio
The next generation of dependable embedded systems feature autonomy and higher levels of interconnection. Autonomy is commonly achieved with the support of artificial intelligence algorithms that pose high computing demands on the hardware platform, reaching a high performance scale. This involves a dramatic increase in software and hardware complexity, fact that together with the novelty of the technology, raises serious concerns regarding system dependability. Traditional approaches for certification require to demonstrate that the system will be acceptably safe to operate before it is deployed into service. The nature of autonomous systems, with potentially infinite scenarios, configurations and unanticipated interactions, makes it increasingly difficult to support such claim at design time. In this context, the extended networking technologies can be exploited to collect post-deployment evidence that serve to oversee whether safety assumptions are preserved during operation and to continuously improve the system through regular software updates. These software updates are not only convenient for critical bug fixing but also necessary for keeping the interconnected system resilient against security threats. However, such approach requires a recondition of the traditional certification practices.
"Moving fast, and breaking things", instead of "being safe and secure", is the credo of the IT industry. However, if we look at the wide societal impact of IT security incidents in the past years, it seems like it is no longer sustainable. Just like in the case of Equifax, people simply forget updates, just like in the case of Maersk, companies do not use sufficient network segmentation. Security certification does not seem to help with this issue. After all, Equifax was IS027001 compliant.In this paper, we take a look at how we handle and (do not) learn from security incidents in IT security. We do this by comparing IT security incidents to early and later aviation safety. We find interesting parallels to early aviation safety, and outline the governance levers that could make the world of IT more secure, which were already successful in making flying the most secure way of transportation.
Blockchain technology is the cornerstone of digital trust and systems' decentralization. The necessity of eliminating trust in computing systems has triggered researchers to investigate the applicability of Blockchain to decentralize the conventional security models. Specifically, researchers continuously aim at minimizing trust in the well-known Public Key Infrastructure (PKI) model which currently requires a trusted Certificate Authority (CA) to sign digital certificates. Recently, the Automated Certificate Management Environment (ACME) was standardized as a certificate issuance automation protocol. It minimizes the human interaction by enabling certificates to be automatically requested, verified, and installed on servers. ACME only solved the automation issue, but the trust concerns remain as a trusted CA is required. In this paper we propose decentralizing the ACME protocol by using the Blockchain technology to enhance the current trust issues of the existing PKI model and to eliminate the need for a trusted CA. The system was implemented and tested on Ethereum Blockchain, and the results showed that the system is feasible in terms of cost, speed, and applicability on a wide range of devices including Internet of Things (IoT) devices.
The JavaCard multi-application platform is now deployed to over twenty billion smartcards, used in various applications ranging from banking payments and authentication tokens to SIM cards and electronic documents. In most of those use cases, access to various cryptographic primitives is required. The standard JavaCard API provides a basic level of access to such functionality (e.g., RSA encryption) but does not expose low-level cryptographic primitives (e.g., elliptic curve operations) and essential data types (e.g., Integers). Developers can access such features only through proprietary, manufacturer-specific APIs. Unfortunately, such APIs significantly reduce the interoperability and certification transparency of the software produced as they require non-disclosure agreements (NDA) that prohibit public sharing of the applet's source code.We introduce JCMathLib, an open library that provides an intermediate layer realizing essential data types and low-level cryptographic primitives from high-level operations. To achieve this, we introduce a series of optimization techniques for resource-constrained platforms that make optimal use of the underlying hardware, while having a small memory footprint. To the best of our knowledge, it is the first generic library for low-level cryptographic operations in JavaCards that does not rely on a proprietary API.Without any disclosure limitations, JCMathLib has the potential to increase transparency by enabling open code sharing, release of research prototypes, and public code audits. Moreover, JCMathLib can help resolve the conflict between strict open-source licenses such as GPL and proprietary APIs available only under an NDA. This is of particular importance due to the introduction of JavaCard API v3.1, which targets specifically IoT devices, where open-source development might be more common than in the relatively closed world of government-issued electronic documents.
In the modern security-conscious world, Deep Packet Inspection (DPI) proxies are increasingly often used on industrial and enterprise networks to perform TLS unwrapping on all outbound connections. However, enabling TLS unwrapping requires local devices to have the DPI proxy Certificate Authority certificates installed. While for conventional computing devices this is addressed via enterprise management, it's a difficult problem for Internet of Things ("IoT") devices which are generally not under enterprise management, and may not even be capable of it due to their resource-constrained nature. Thus, for typical IoT devices, being installed on a network with DPI requires either manual device configuration or custom DPI proxy configuration, both of which solutions have significant shortcomings. This poses a serious challenge to the deployment of IoT devices on DPI-enabled intranets. The authors propose a solution to this problem: a method of installing on IoT devices the CA certificates for DPI proxy CAs, as well as other security configuration ("security bootstrapping"). The proposed solution respects the DPI policies, while allowing the commissioning of IoT and IIoT devices without the need for additional manual configuration either at device scope or at network scope. This is accomplished by performing the bootstrap operation over unsecured connection, and downloading certificates using TLS validation at application level. The resulting solution is light-weight and secure, yet does not require validation of the DPI proxy's CA certificates in order to perform the security bootstrapping, thus avoiding the chicken-and-egg problem inherent in using TLS on DPI-enabled intranets.
This paper presents an overview of the H2020 project VESSEDIA [9] aimed at verifying the security and safety of modern connected systems also called IoT. The originality relies in using Formal Methods inherited from high-criticality applications domains to analyze the source code at different levels of intensity, to gather possible faults and weaknesses. The analysis methods are mostly exhaustive an guarantee that, after analysis, the source code of the application is error-free. This paper is structured as follows: after an introductory section 1 giving some factual data, section 2 presents the aims and the problems addressed; section 3 describes the project's use-cases and section 4 describes the proposed approach for solving these problems and the results achieved until now; finally, section 5 discusses some remaining future work.
SSL certificates are a core component of the public key infrastructure that underpins encrypted communication in the Internet. In this paper, we report the results of a longitudinal study of the characteristics of SSL certificate chains presented to clients during secure web (HTTPS) connection setup. Our data set consists of 23B SSL certificate chains collected from a global panel consisting of over 2M residential client machines over a period of 6 months. The data informing our analyses provide perspective on the entire chain of trust, including root certificates, across a wide distribution of client machines. We identify over 35M unique certificate chains with diverse relationships at all levels of the PKI hierarchy. We report on the characteristics of valid certificates, which make up 99.7% of the total corpus. We also examine invalid certificate chains, finding that 93% of them contain an untrusted root certificate and we find they have shorter average chain length than their valid counterparts. Finally, we examine two unintended but prevalent behaviors in our data: the deprecation of root certificates and secure traffic interception. Our results support aspects of prior, scan-based studies on certificate characteristics but contradict other findings, highlighting the importance of the residential client-side perspective.
Software Defined Network (SDN) is a revolutionary networking paradigm which provides the flexibility of programming the network interface as per the need and demand of the user. Software Defined Network (SDN) is independent of vendor specific hardware or protocols and offers the easy extensions in the networking. A customized network as per on user demand facilitates communication control via a single entity i.e. SDN controller. Due to this SDN Controller has become more vulnerable to SDN security attacks and more specifically a single point of failure. It is worth noticing that vulnerabilities were identified because of customized applications which are semi-independent of underlying network infrastructure. No doubt, SDN has provided numerous benefits like breaking vendor lock-ins, reducing overhead cost, easy innovations, increasing programmability among devices, introducing new features and so on. But security of SDN cannot be neglected and it has become a major topic of debate. The communication channel used in SDN is OpenFlow which has made TLS implementation an optional approach in SDN. TLS adoption is important and still vulnerable. This paper focuses on making SDN OpenFlow communication more secure by following extended TLS support and defensive algorithm.