Upload
ashlynn-payne
View
212
Download
0
Tags:
Embed Size (px)
Citation preview
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