5. Security in the IPN

(1)

1. Introduction

2. Inter-Internet Dialogs

3. Building a stable Backbone for the IPN 4. IPN Nodes

5. Security in the IPN

6. Deployed Internets in the IPN 7. Working conclusions

(2)

5.1. Introduction - Overview

• Currently no users – so difficult to plan detailed security mechanisms

• it’s yet sure THAT security is required:

– Interplanetary Internet will be interesting for hackers, due to limited bandwidth little hacking success fatal would be fatal – a lot of private and precious data will be sent in the IPN

• applied at application layer

• until now orientation on the E-Mail security mechanisms and services on earth’s internet

• Aspects:

– protection of IPN infrastructure and protection of the data (“bundles”)

– exchange routing information and manage routing securely

(3)

5.2. Required security mechanisms

• Access control

– limited access protects against overloading by unauthorized application

– Authentication required, verify identity of the source of network traffic

5. Security

• Data integrity

– ensure that received data is the same as initially sent across the IPN

– should make unauthorized modification of data detectable

• Data privacy

– provide confidentiality

– only those who are authorized to obtain traversing data should have access

(4)

5.3. Types of security paradigms

• hop-by-hop security (”link security”)

– data including routing informations protected at source, must be unprotected at each trusted routing point in order to route – before sending to next point, data including routing

information is reprotected and then send

– problem: depending on what is defined as a protected area (are gateways trusted ?), data is potentially vulnerable to modification or disclosure

• end-to-end security

– no trusted gateways, everything on the path between source and destination is seen as hostile

– so data protected at source, never unprotected until destination

– routing information must remain unprotected

(5)

5.4. End-to-end Security

– end-to-end paradigm preferred, but several problems to solve – end-to-end security requires end-to-end protocols and a protocol

below the data that provides ability to route

– so end-to-end protection can only be applied to the data itself and on no layer beyond

-> the same way SSL (Secure Sockets Layer) and secure email techniques (S/MIME, OpenPGP) work

– important to leave packet's protocol headers open for intermediate systems

– because Interplanetary Internet is very email-like (non-interactive, parties don‘t necessary have communicated before), this

possibility is discussed more intensive 5. Security

(6)

5.5. Secure E-Mail technology (1)

• Encryption, Digitally Signatures (Authentication) -> Public key cryptography

– Encryption: E-Mail sender uses public key of recipient to encrypt the data, recipient uses his private key to decrypt

– Digitally Signatures: E-Mail sender uses his private key to sign the message, recipient verifies message the public key of the sender

(7)

• Problems

– public key cryptography needs a lot of processor power – public key cryptography needs a lot of bandwidth

• necessary that all communication parties know each others public keys and exchanging some random information („Diffie-Hellmann- Exchange“)

• therefore near-real-time-environment needed, which is not practical in the IPN

– difficulties to communicate with unknown parties

5. Security

(8)

• A way to solve at least one problem ?

– Symmetric keys could save processor power (encryption and decryption easier), but are not usable in IPN (no save way to send the key)

– Idea for encryption: E-Mail sender encrypts data with a brand new generated symmetric key and uses Public Key

Cryptography only to encrypt the key itself

data data

encrypted data

Symmetric key

Recipient’s public key

encrypted key

Recipient’s private key

encrypted data

Symmetric key

(9)

– Digitally signatures: sender creates a hash of the message with a common algorithm (MD5, SHA-1, ...)

– only the hash is signed with Public Key Cryptography:

data data

data

Hash Algorithm

Senders private key

signed hash

Senders public key

data

Hash Algorithm

– still additional bandwidth required, no solution for that

– for communication with new parties it’s necessary to find out their public key

5. Security

(10)

5.6. Using Secure E-Mail Technology in the IPN (1)

• for making the system work, a public key infrastructure (PKI) will be needed in the IPN

– even “only on earth“ several problems about that:

• competing PKIs, how to cross-certify public keys ?

• who is the root certification authority of the whole system ?

– personal public keys are spread by public key-servers or attached on E-Mails

– in the IPN: public key servers won‘t work in the same way as on earth - problem similar to the difficulties with the DNS-System as described

(11)

5.6. Using Secure E-Mail Technology in the IPN (2)

– not possible to contact PKI-servers on Earth (delays !) – local server might exist, but would quickly drop out of

synchronization, -> certificates change

– solution:

• PKI-servers only on earth, only contactable by earth-based senders

• Entities not on earth get a set of preplaced public keys of IPN entities to which communication makes sense

• IPN sender shall always include their public key in every bundle ->costs additional bandwidth, but solves the delay-problem

5. Security

(12)

5.7. Protecting the IPN infrastructure

• important, that no unidentified entities can join network

• so every entity must authenticate itself

– verify identity, access controls to allow communication

• infrastructure information (routing updates, node management information, ...) need to be protected

• the same security mechanisms as for data seem to be possible

– in that case, hop-by-hop-security a good choice

– „bundle aware application“ (bundle-agent), signs or encrypts the special infrastructure payload

– receiving IPN node must check the signature by comparing to access control list

(13)

1. Introduction

5. Security in the IPN

6. Deployed Internets in the IPN

7. Working conclusions

(14)

6.1. Introduction

• Examples for a deployed internet, possible configurations:

– single lander hosting interplanetary gateway

– cooperating robots on a foreign planet, maybe communication via low-orbiting satellites that contain interplanetary gateways – spacecraft-onboard networks

– earth‘s internet

(15)

6.2. Applications of deployed internets

• Until now only basic ideas, model will maybe never reflect actual use of the IPN:

1 return of scientific data usually not time-sensitive except power considerations

2 telemetry information, often as unreliable transmission, delivery either stream-oriented or periodically

3 command and control of in-situ elements, endpoint could be separated by interplanetary space, has to be designed to work with necessary delays (Quality of service!)

4 telescience and virtual presence, great volumes of information, great chances, but still development needed

6. Deployed Internets in the IPN

(16)

6.3. Characteristics compared to earth‘s internet (1)

• Energy Problems

– internet on earth mostly wired networks, cheap energy

– mobile ad hoc networks (MANET) use the same cheap power – On other planets the only power is the sun, relativ inefficient

– diminishes on moving away from sun (Mars Orbit: less than half W/m² as on earth), even more dramatic on surface of planet

– dictates a need for efficient protocols at all layers

• Signal-to-noise ratios

– very high in wired networks – in terrestrial MANETs lower

– will be VERY low in deployed internets (power!)

(17)

6.3. Characteristics compared to earth‘s internet (2)

• Routing infrastructure

– on earth mostly fixed, only satellites mobile

– in IPN: will be nearly only mobile, many satellites, will use mainly radio frequency even for permanent stations

• Costs

– installing and running a network on earth very cheap

– on other planets very expensive: landing, deploying, operating and repairing

– as much infrastructure as possible should be low-orbiting satellites

– only antennas for wideband communication on planets to keep costs as low as possible

(18)

6.4. Characteristics of protocol layers (1)

• Actual realization still in development

• Physical layer:

– use of radio-frequency spectrum not regulated until now – certain frequency bands very attractive for use in space

• Link layer:

– manage low Signal-to-Noise ratios by using different coding schemes, e.g. convolutional coding, concatenated codes (Reed Solomon code), Turbo codes

– each code has different properties for different characteristics – reserve resources for control operations

– link-layer status detection (availability, capacity, congestion, current errors), report to network layer

(19)

• Network Layer:

– routing protocols for fast and slow moving mobile nodes in combination with fixed nodes

– “vertical handoffs”, adapt changes in links on lower layers – mechanisms for self-configuration of the mobile elements

(address allocation, name-to-address binding, dynamic hierarchical organization)

• Transport Layer

– new protocols for power efficient communication schemes between mobile entities, must be able to adapt to changing network conditions

– some links will have asymmetric data rates, important to handle this and stay power efficient

(20)

• Application layer

– enable service location, necessary at startup and after networks became partitioned

– monitoring the status and health of mobile nodes

• not possible to guarantee any capacity in deployed network

• power limitations will be a problem for a long time

• exchange of components often not possible, important to build a robust system that is easy to repair

(autonomously ?)

6.5. Comments

(21)

1. Introduction

5. Security in the IPN

7. Working conclusions

(22)

• all future space missions include vehicles which have to communicate with another (landers, rovers, orbiters ...)

• delay is the only problem that can not be solved

• various deployed internet have to be connected by stable interplanetary gateways

• most of today‘s internet application can‘t be used in interplanetary internet, only SMTP after several

modifications

(23)

• IPN names should be represented in tupels

• IPN nodes will have to work as a store-and-forward- system for long-delay connections

• security has to be flexible and bandwidth-efficient

• long-haul transport protocol must be connectionless, so different from TCP

• deployed internets may use TCP, but other solutions are also possible

7. Working conclusions