Health Management Scenario

1
Remote Terminal Management (RTM) and Access
Control in SPACE4U

Hailiang Mei H.Mei_at_tue.nl
2
Outline

• Goals of RTM
• Possible RTM Approaches (review of existing
  solutions)
• Consideration on Security and Access Control
• Design of RTM Framework
• Conclusion and Future Work

3
Scenarios
Self observes problem Remote diagnosis
Remote Repair
Remote server can be within local network or at
service providers site
4
Requirements for RTM

• Secured RTM (RTM.01, mandatory)
• Management client oriented
• Healthy terminal oriented
• Component downloading due to context changing
  (CAC.0102)
• (Legal) Component sharing (RTM.02, optional)
• Service discovery (RTM.03, optional)
• Non-healthy terminal oriented
• Remote diagnosis (RTM.04, similar to HM.03,
  Mandatory )
• Remote repair (RTM.05, similar to HM.04,
  Mandatory )
• Management server oriented
• User service data survey (RTM.06, optional)
• User transparent control (RTM.07, Mandatory)

5
Outline

• Goals of RTM
• Possible RTM Approaches (review of existing
  solutions)
• Consideration on Security and Access Control
• Design of RTM Framework
• Conclusion and Future Work

6
Possible RTM approaches

• Telnet/SSH
• Virtual Network Computing (VNC)
• Web server
• UPnP
• SNMP
• SyncML (Open Mobile Alliance)

7
Virtual Network Computing
8
Virtual Network Computing
9
Web Server

• The device runs a small web server application
• A service runs on the device to generate run-time
  HTML file
• The remote terminal manager access the device via
  the web browser and execute scripts on the device

10
Web Server (example)
11
UPnP
Overall stack
Control stack
12
SNMP
13
SNMP (example)
14
SyncML DM (OMA)
OMA DM
Over the air
15
SyncML DM (OMA)
OMA DM

• Server
• ltGetgt
• ltCmdIDgt4lt/CmdIDgt
• ltItemgt
• ltTargetgt
• ltLocURIgtVendor/Ring_signals/Default_ringlt/LocUR
  Igt
• lt/Targetgt
• lt/Itemgt
• lt/Getgt
• Client
• ltResultsgt
• ltCmdRefgt4lt/CmdRefgt
• ltCmdIDgt7lt/CmdIDgt
• ltItemgt
• ltDatagtMyOwnRinglt/Datagt
• lt/Itemgt
• lt/Resultsgt

16
SyncML DM (OMA)
OMA DM
17
Review of approaches

• Virtual Network Computing (VNC, open source)
  (Dropped due to obvious security problems)
• Web server (Dropped due to less flexibility and
  limited functionalities)
• UPnP based (Dropped due to less competitive with
  SyncML DM)
• SNMP based (Continuing as the complementary)
• SyncML DM (Continuing as the main reference)

18
Outline

• Goals of RTM
• Possible RTM Approaches (review of existing
  solutions)
• Consideration on Security and Access Control
• Design of RTM Framework
• Conclusion and Future Work

19
Scenario
RTM Server
RTM Client
20
Hacker on the link
RTM Server
RTM Client
21
Hacker on RTM Server
RTM Server
RTM Client
22
User is a Hacker
RTM Server
RTM Client
23
Hackers 4 ALL
RTM Server
RTM Client
CIA non-repudiation
24
Kill Hackers
RTM Server
RTM Client
PKI is the solution !
25
Security and Access Control

• Security assurance
• PKI solve confidentiality, integrity and
  non-repudiation
• Access Control
• Tree structure access control list looks
  promising, which is included by SNMP, Microsoft
  Active Directory and SyncML

26
Outline

• Goals of RTM
• Possible RTM Approaches (review of existing
  solutions)
• Consideration on Security and Access Control
• Design of RTM Framework
• Conclusion and Future Work

27
Relation with SIM
get/exec
add/replace delete/exec
28
RTM Framework inside Device
29
Access Management for RTM

• Each node (object) is identified by an URI
• Each node has a set of properties
• This tree can be extended by add message or a
  new installations on the device
• Leaf node can be either a value or a pointer to
  an executable command

30
Secure Communication

• Authentication
• Decryption and encryption
• Maintain log file
• Can keep user update with latest operations
  (Transparent control)

31
Comply with ROBOCOP Framework
OS/drivers

• RCDP component is available
• Scommunication can be implemented based on
  open-SSL and SyncML protocol stack
• Access Manager is open

32
Conclusion

• Secured RTM (RTM.01, mandatory)
• Management client oriented
• Healthy terminal oriented
• Component downloading due to context changing
  (CAC.0102)
• (Legal) Component sharing (RTM.02, optional)
• Service discovery (RTM.03, optional)
• Non-healthy terminal oriented
• Remote diagnosis (RTM.04, similar to HM.03,
  Mandatory )
• Remote repair (RTM.05, similar to HM.04,
  Mandatory )
• Management server oriented
• User service data survey (RTM.06, optional)
• User transparent control (RTM.07, Mandatory)

33
Conclusion

• Secured RTM (RTM.01, mandatory) ?
• Management client oriented
• Healthy terminal oriented
• Component downloading due to context changing
  (CAC.0102)
• (Legal) Component sharing (RTM.02, optional) ?
• Service discovery (RTM.03, optional) ?
• Non-healthy terminal oriented
• Remote diagnosis (RTM.04, similar to HM.03,
  Mandatory) ?
• Remote repair (RTM.05, similar to HM.04,
  Mandatory ) ?
• Management server oriented
• User service data survey (RTM.06, optional) ?
• User transparent control (RTM.07, Mandatory) ?

34
Future Work

• Formulate access control mechanism
• Some ideas borrowed from SNMP and SyncML
• Limiting the root node access rights properties
• Certain access management might be done by
  interacting with users
• Define communication protocol and message format
• Largely based on SyncML
• Implementing

35
Questions?