The Dutch interbank computer network

At the end of 1980, a strategic decision was made by the Dutch banks and savings banks to commence the development of a Data Communications Infrastructure (DCI), to be used for a number of forthcoming interbank applications. It was agreed that this new data communications infrastructure should be based on the emerging Reference Model for Open Systems Interconnection (OSI). The first interbank application using the DCI (i.e. urgent money transfers) was introduced in the second quarter of 1985. Other interbank applications, which will also make use of the functions provided by the DCI, are currently being developed.\ud \ud This paper provides the background to the DCI project, discusses the selection of OSI standards for the network, and gives an overview of the design of the software package, which was developed to support the selected OSI standards

To Share or Not to Share in Client-Side Encrypted Clouds

With the advent of cloud computing, a number of cloud providers have arisen to provide Storage-as-a-Service (SaaS) offerings to both regular consumers and business organizations. SaaS (different than Software-as-a-Service in this context) refers to an architectural model in which a cloud provider provides digital storage on their own infrastructure. Three models exist amongst SaaS providers for protecting the confidentiality data stored in the cloud: 1) no encryption (data is stored in plain text), 2) server-side encryption (data is encrypted once uploaded), and 3) client-side encryption (data is encrypted prior to upload). This paper seeks to identify weaknesses in the third model, as it claims to offer 100% user data confidentiality throughout all data transactions (e.g., upload, download, sharing) through a combination of Network Traffic Analysis, Source Code Decompilation, and Source Code Disassembly. The weaknesses we uncovered primarily center around the fact that the cloud providers we evaluated were each operating in a Certificate Authority capacity to facilitate data sharing. In this capacity, they assume the role of both certificate issuer and certificate authorizer as denoted in a Public-Key Infrastructure (PKI) scheme - which gives them the ability to view user data contradicting their claims of 100% data confidentiality. We have collated our analysis and findings in this paper and explore some potential solutions to address these weaknesses in these sharing methods. The solutions proposed are a combination of best practices associated with the use of PKI and other cryptographic primitives generally accepted for protecting the confidentiality of shared information

Options for Securing RTP Sessions

The Real-time Transport Protocol (RTP) is used in a large number of different application domains and environments. This heterogeneity implies that different security mechanisms are needed to provide services such as confidentiality, integrity, and source authentication of RTP and RTP Control Protocol (RTCP) packets suitable for the various environments. The range of solutions makes it difficult for RTP-based application developers to pick the most suitable mechanism. This document provides an overview of a number of security solutions for RTP and gives guidance for developers on how to choose the appropriate security mechanism

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

Post-processing procedure for industrial quantum key distribution systems

We present algorithmic solutions aimed on post-processing for industrial quantum key distribution systems with hardware sifting. The main steps of the procedure are error correction, parameter estimation, and privacy amplification. Authentication of a classical public communication channel is also considered.Comment: 5 pages; presented at the 3rd International School and Conference "Saint-Petersburg OPEN 2016" (Saint-Petersburg, March 28-30, 2016