IAEA

RAINSTORM

Christoph Brunhuber, Keith Morgan, Jim RegulaRemote Monitoring Team

Safeguards, IAEA

2014-09-08

IAEA

Outline

• History / Motivation• RAINSTORM

• Data Transfer: HTTP + REST• Data Organization Details

• Data Security: PKI• PKI on “ultra-light” devices

• Efficiency Details• Source Code Sample Implementations

• Use Cases• Forecast

• Conclusion

IAEA

History / Motivation

• Remote Monitoring has gradually expanded over the last ~15 years• In the beginning…

• Data Transfer• Instruments (i.e. sensors) connected to a PC (typically via serial port)• Transferred from PC to Vienna via SMB or FTP or …

• RoboCopy, XCopy• In-house developed software (e.g. DCCopy)• Large overhead for small files• Inefficient for high latency networks

• Data Security• Instruments (i.e. sensors) had symmetric-key data security or no data security• Symmetric-key data security has issues, e.g.

• Private key is exposed (easier to be lost or stolen)• Each verifier is able to forge data

• In case of RSA, data are signed on the collect PC

IAEA

History / MotivationIAEA Safeguards Equipment Cross Section

• NDA• MiniGrand; JSR

• RS232 & SMB• RSA Signing

on collect PC

• VIFM; ATPM• Proprietary &

SMB• RSA Signing

on collect PC

• UNAP• HTTP• RSA Signature• (RAINSTORM compliant)

• NGAM (future)• RAINSTORM

• OLEM (future)• RAINSTORM

• Surveillance• DMOS; SDIS

• Proprietary & SMB• MAC Signing

• NGSS• HTTPS• DSA & RSA Signatures• (almost RAINSTORM compliant)

• Seals• EOSS/VACOSS

• Proprietary• MAC

• RMSA• RAINSTORM (only HTTP)• MAC

• LMCV (Future)• RAINSTORM

IAEA

History / MotivationGoals for RAINSTORM

• Low complexity, and low resource requirements -should run on Microcontrollers

• Ethernet based• Suitable for high latency networks (no Stop and Wait)• No need for intermediate collect PC• Efficient broken transfer recovery• Overall good performance• Signature as close as possible to data acquisition and

NO resigning (implies strictly appending of data files)

IAEA

History / Motivation

Q: What can we learn from the shipping industry?

A: Standards!

Ship image source: http://www.cargocontainercentre.com/wp-content/uploads/2011/10/container-ships1.jpgTrain image source: http://www.marine-knowledge.com/wp-content/uploads/2011/07/ship-containers-transported-by-train.jpgTruck image source: http://www.marine-knowledge.com/wp-content/uploads/2011/07/ship-container-on-truck.jpg

IAEA

RAINSTORM

Real-time And INtegrated STream-Oriented Remote Monitoring (RAINSTORM) interface

Image source: http://www.phdcomics.com/comics.php?f=1100

IAEA

RAINSTORM

• It’s just a “concept”• Requirements captured in SG-UR-11979 “Remote Monitoring

Requirements for the Development of IAEA Safeguards Equipment”

• Achieved Goals• Standardize data transfer and data security

• Data Transfer: Ethernet + TCP/IP + HTTP + REST• Data Security: PKI + Smartcard tokens

• Eliminate the PC (reduced maintenance, reduced power) i.e. everything on the instrument

• Provide in-house developed tools/libraries/applications (with source code!) to vendors for prototyping and/or production

IAEA

Data Transfer: HTTP + REST

• Hypertext Transfer Protocol (HTTP)• Simple, lightweight, ubiquitous (used billions of times per

day!!!)• Not just for web pages, also well-suited to binary data

• HTTP ≠ HTML

• Incremental file transfers: efficient use of bandwidth• Persistent/Stateless connections

• REpresentational State Transfer (REST)• Each file and folder has a unique URI• Standard HTTP methods (e.g. GET)• No need for “fancy” protocols on top of HTTP (e.g. SOAP)

IAEA

Data Organization Details

• Data Storage• Organization of data into “day files”

• e.g. xvie-ngss-2014-08-21.mpg• Strictly appended (see previous page)

• Organization of files into “month folders”• e.g. /data

/2014-08

/2014-07

/2014-06

…• Consider the problems with a flat file structure or even one file per

folder (e.g. “day folders”)

IAEA

Data Security: PKI

• Public key infrastructure (PKI)• Public/Private (i.e. asymmetric) keys• Certificates & Certification Authorities (CA)

• Smartcard security tokens• Private key generation / operations performed on token

• Cryptographic Message Syntax (CMS, S/MIME, PKCS#7)• ASN.1-based binary format• Contains certificates, message digest, signature, etc.

• RM-specific Requirements• “detached” signature files• Include all certificates up to,

but excluding the root CA certificate

Source: http://www.cardcontact.de/images/sc-hsm-600x300.jpg

IAEA

PKI on “Ultra-light” Devices

• Using a token requires:• usb (e.g. libusb)• ccid• pcsc-lite• opensc• cryptlib (or openssl etc.)

• All this on a low-power embedded device? Yikes!• Way too complex! (could be majority of development effort)• Fortunately we typically need only one operation: sign

IAEA

PKI on “Ultra-light” Devices cont.

• sc-hsm-ultralite• Joint development with CardContact (Germany)• lightweight PKCS#11 (read-only) driver• “ultralite” raw CCID driver

• Includes in-house developed PKCS#7 template library for simple “detached” signature creation

• IAEA fork available at:• https://github.com/sc-hsm-clone/sc-hsm-embedded

IAEA

Efficiency Details

Incremental transfer allows near real-time data collection and efficient recovery from broken transfers. (Resending all data, i.e. old and new, increases transfer volume by factor of + 1)/2 where (�n is the number of transfers for a single entity). Incremental transfer is always possible because data are strictly appended.

Using many small data files eliminates the inefficiency, but creates too many items. A good compromise: 1 data file per day.

TCP uses a so-called sliding window for optimal bandwidth utilization. Stop and Wait is idle when waiting for an acknowledgement.

TCP handles automatic retransmits in case of transmission failures.

IAEA

Efficiency Details

Organizing data in month folder is a good compromise for device data exploration.

Day folders result in too many directory requests, while a flat structure results in too many entries per directory.

By design a cryptographic hash cannot be continued, however it can be forked – one path finalizes the hash, the other path continues hashing.

Suppose an entity has its signature updated n times per day. Restarting the hash from the beginning at each signing results again in the inefficiency factor + 1)/2, e.g. if n = 60 seconds: requires ~720MB (�hashing for each MB.

The hashing operation is NOT performed on the Cryptographic Smart Card.

IAEA

Source Code Sample Implementations

Name Description OS Support Notes

RainstormX A module for use with the Microsoft IIS HTTP server.

C# Windows Complete. In testing.

RainstormC# Complete HTTP server built on the .NET HttpListener framework.

C# Windows, Linux (using mono) Complete. In testing.

RainstormPHP PHP module for use with any HTTP server that supports PHP.

C# Windows, Linux, etc. (to-date only tested on Linux w/ Apache)

Complete. In testing.

Mongoose A patch of the complete open-source Mongoose HTTP server.

C Only intended for micro-controllers.

Incomplete.Not tested.

sc-hsm-ultralite

Ultra lightweight digital file signing library/tools/applications.

C Windows, Linux (portable to other operating systems)

Complete. In testing.

In-house developed code provided, on request, to external vendors.

IAEA

Use Cases

HTTPServer

DataSecurity

Y-specific

code

Custom Instrument Y

Z-specific code

Off-the-shelf Instrument Z

HTTPServer

DataSecurity

X- specific

code

Custom Instrument X

Network

RM Data Center

H D

Rainbox

IAEA

Forecast

• Rainstorm-enabled equipment in the SGTS pipeline• Production

• NGSS (vendor implementation)

• Testing• RMSA (RainstormPHP + HMAC)• OLEM (RainstormPHP + sc-hsm-ultralite)• NGAM (RainstormPHP + sc-hsm-ultralite)• LMCV (RainstormX + opensc)• UNAP (vendor implementation)

• Potential• Lynx (TBD)• Rainbox + any off-the-shelf device

• dogfooding• RM regional office servers (RainstormC#)• Legacy UMS instruments: VIFM, MiniGrand, etc.

(RainstormC# + sc-hsm-ultralite)

IAEA

Conclusion

RAINSTORM unifies data organization, transfer and security for all kinds of sensors. It does not define data formats, but requires a format which strictly appends new data.

The sensor platform requires a TCP/IP over Ethernet implementation and USB access to the cryptographic Smartcard. All RAINSTORM components work on top of these requirements and can be implemented easily. An instrument should be able to store several months of data locally.

The motivation for RAINSTORM includes: eliminate a local PC in the field and reducing proprietary software for remote monitoring usage and data signing (on the PC).

The transfer channel is a secure VPN tunnel, managed by approved VPN devices, through the public Internet (out of the scope of RAINSTORM).

The chosen HTTP protocol allows arbitrary additional metadata which can be used to implement special applications on top of RAINSTORM.