An Adaptable Security Manager for Real-Time Transactions

Sang H. Son and Robert ZimmermanDept of Computer Science

University of Virginia

Jorgen HanssonDept of Computer and Information Science

Linkoping UniversitySweden

Overview

• Motivation & Introduction

• Research Issues for Info Assurance

• Flexible Security Manager Design

• Evaluation

• Conclusions & Future Work

Trends

• Increasing number of systems operate in unpredictable (even hostile) environments

– task set, resource requirements (e.g., wcet) ... • High assurance required for performance-critical

applications• System properties for high assurance

– real-time (timeliness, temporal consistency ..)– security (confidentiality, authentication ..)– fault-tolerance (availability, reliability ..)

• Each property has been studied in isolation

Motivation

• BeeHive: distributed OODB supporting RT, FT, security, and QoS

• Need for resource tradeoffs in database services• Adaptable security paradigm fits well with the

concept of multiple service levels of BeeHive• Short term relaxation of security could be

preferable to missed critical deadlines– aircraft attack warning during burst of

battlefield updates– loss of production time for missed agile

manufacturing command

Real-Time Database System• Characteristics

– transactions with timing constraints– data with validity interval

• Requirements– timeliness (min deadline miss ratio)– temporal consistency (proximity with real world)– predictability

• Issues– scheduling (best-effort vs guarantee)– correctness (ACID properties and appl semantics)– embedded and mobile data support

Database Security• Security services

– to safeguard sensitive information– encryption, authentication, intruder detection ...

• Multilevel security (MLS)– objects are assigned with security classification– subjects access objects with security clearance– no flow of information from higher level to lower one

• Applications– almost everywhere (becoming a buzzword)– more flexibility necessary (from static, known

environment to dynamic unknown environment)

Security and Real-Time

• For timeliness, no priority inversion in real-time applications

- tasks with earlier deadline or higher criticality has higher

priority for better service

• In traditional secure systems, no security violation is allowed (binary notion of security)

• Incompatible under the binary notion of absolute security

– priority inversion vs security violation

• Higher security level needs more resources

Example of Problem

• Both require lock on the resource

• How to resolve this conflict?

• if lock is given to T1, security violation

• if lock is given to T2, priority inversion

T1- high priority

- high security

T2- low priority

- low securityAccess Access

Research Issues

Supporting multiple facets of information assurance:

how to provide acceptable security

services while remains available and provides timely performance for essential tasks

Research Issues

• Flexible security vs absolute security– paradigm for flexible assurance services– identifying correct metrics for assurance level

• Adaptive system assurance policies • Mechanisms to enforce required level of assurance

– access control, authentication, encryption, ..– time-cognizant protocols, data deadlines, ...– replication, primary-backup, ...

• Specification to express desired system behavior – verification of consistency/completeness of

specification

Flexible Security Services• Flexible vs absolute (binary) security

– traditional notion of security is binary: secure or not

– problem of binary notion of security: difficult to provide acceptable level of security to satisfy other conflicting requirements

– research issue: quantitative flexible security levels

• One naive approach may use % of potential/actual security violations– problem: not precise --- percentage alone reveals

nothing about implications on system security

e.g., 1%violation may leak most sensitive data out

System Features

• Four available security levels on users/objects or communications

– computation costs increase with level of security

• Client negotiated range of security levels for transaction communications

• Dynamic level changes as a function of real-time load

Security Manager Services

• Multi-level authentication and confidentiality

encryption

• Client authorization and session control

• Session key generation and management

• Transaction management

• Dynamic security level control for transaction

communications and synchronization

Algorithm Selection

Method Rationale

Authentication

level 3 MD5 + RSA digital signature

level 2 MD5 + RC5 fast word oriented

level 1 QuickAuth simple single round

Confidentiality

level 3 IDEA strong mathematical basis

level 2 RC5 fast word oriented

level 1 QuickCipher simple single round

Security Manager Environment

session & transactionrequests

Security Manager

ClientTable

SessionTable

Beehive

TransDatatransaction results

thread nthread n-1

DB

Scheduler

Mapper/Admission

Control

data flow

execution control

transaction object &session data

client security level & key

session keys & status transaction

handoff

object read & write

SecurityManager

clientID authorizedGroup(s) SecurityLevel publicKey|modulus

cid8333 grp0321 3 1dcd6503 | 0bb8fc24fd29

cid5489 grp1229,grp1230 2 53e67fb2

. . . Client Table

ActiveSessionTable

clientID/Session links

level/authorized groups

Client

Session Request Process

clientID nonce1 nonce2 sessionKeys signature

confirmation

clientID reqType reqTime lowLevel nonce1 MAC

session request

Session keys,endTime

encrypted with stored client key

encrypted with Security Manager public key

Client Authentication

session request digest

hashfunction

encryptionMAC encryption

(message privacy)

securemessage w/authentication

MD5MD5RXOR

RSA (client)RC5Key RXOR

RSA (Sec Mgr)RSA (Sec Mgr)RSA (Sec Mgr)

Level 3:Level 2:Level 1:

algorithm

• Client creates message:

• Security Manager re-calculates MAC and compares with client’s MAC

Security Manager Authentication

response to session request

digesthash

functionencryption

MAC encryption (message privacy)

securemessage w/authentication

MD5MD5RXOR

RSA (client)RC5Key RXOR

RSA (client) RC5 QuickCipher

Level 3:Level 2:Level 1:

algorithm

• Security Manager creates message:

• Client re-calculates MAC and compares with Security Manager’s MAC

Session Keys

• Derived from pseudo-random number at session initialization

• One for each allowable client level

• Held in KeySet object by Session object

• Destroyed when session endtime is reached

Transaction Request Process

• Evaluates transaction requests encrypted at active session level

• Verifies presence of active client session

• Ensures resource availability through BeeHive Admission Controller (to be implemented)

• Dynamically switches session security levels as required by simulated scheduler (BeeHive scheduler to be implemented)

Security Level Synchronization

Sec Mgr events

Client X events

Client X level

Sn

Sec Mgr level

3210

Rn+1Sn

Sn+1 Rn

prepare for 2 step switch

Sn+2

Rn+1

prepare to switchlast message accounted for

Rn+2

Sn+2

switch

Sn+3

Rn+3

received acknowledgment

time

LEGEND

Sn

Rn

transaction request

request with switch acknowledgment

transaction response message

response with switch command

send the nth message

receive the nth message

t1

t2 t3 t4

t5

Rn

3210

Authentication Timing Measurements

Security Manager processes:

• Decrypt message

• Authenticate client (m2)

• Initiate session

• Pack Response

• Create Security Manager MAC (m3)

• Encrypt response

• Transmit response

end-to-end(m1)

Transaction Timing Measurements

Security Manager processes:

• Decrypt message (m5)

• Perform transaction

• Pack response

• Encrypt response (m6)

• Transmit response

end-to-end(m4)

Algorithm Timing(msec)

level 3 level 2 level 1 level 0Authentication

(m1) end-to-end 2,014.00 698.00 509.00 30.00 (m2) decryption 180.77 1.56 0.75 0.42(m3) encryption 179.79 0.97 0.58 0.42

Confidentiality (w/ 128 bye message)(m4) end-to-end 48.00 41.08 39.92 39.86(m5) decryption 3.47 1.37 0.64 0.25(m6) encryption 3.35 1.19 0.49 0.32

Confidentiality (w/ 8K bye message)(m4) end-to-end 182.56 103.20 62.19 45.64(m5) decryption 67.86 29.30 9.32 0.25(m6) encryption 67.53 29.18 8.60 0.31

Security Manager Test Setup

bhSecInServer

bhSecOutServer

bhSecurity

securityClient

generate client(s) transaction requests

Decrypt & check for level switch

decrypt & createtransaction

decrypt data,get object,do transaction,pack/encrypt/ send message

tsstarttransaction

client message stream in

poll for message

BeeHive DB

store/retrieveobjects

RPC callpthread_create

poll for message

responsesout

tq

Impact of Difference in Message Size

0

50

100

150

200

250

128 2K 4K 6K 8K

message size

time

(mse

c)level 3level 2level 1level 0

Adaptive vs. Non-Adaptive

0

20

40

60

80

100

120

2 1.5 1 0.5 0.2

deadline/mean execution time ratio

% d

eadl

ines

mad

e

100% adaptive

50% adaptive

0% adaptive

Level Switching (100% adaptive client)

0

20

40

60

80

100

120

2 1.5 1 0.5 0.2

deadline/mean execution time ratio

% d

eadl

ines

mad

e

3

2

1

0

L

E

V

E

L

% MADE

LEVEL

Expanded View

a - time from resource drop to detection = approx 10 transactionsb - time from detection to full recovery = approx 50 transactions

70

75

80

85

90

95

100

1.5 1

deadline/mean execution time ratio

% d

ead

lines

mad

e

a

b

Improved Switch Thresholds

0

20

40

60

80

100

120

2 1.5 1 0.5 0.2

deadline/mean execution time ratio

% d

eadl

ines

mad

e

Conclusions

• Good performance gains achievable in soft real-time system during overload conditions

• Reasonable performance with small message sizes with I/O overhead

• Experiments with a real system necessary to confirm results

Future Work

• Incorporate adaptive authentication

• Integrate objects into BeeHive

• Further quantify security manager performance

• Identify other areas for tradeoffs

• Develop rules for security tradeoffs

• Investigate other security services that fit the adaptive paradigm (security QoS)