1 / 20

Preventing Theft of Quality of Service on Open Platforms

Preventing Theft of Quality of Service on Open Platforms. Kwang-Hyun Baek and Sean W. Smith Department of Computer Science Dartmouth College kwang-hyun.baek@dartmouth.edu. This Talk. Goal: Prevent insider’s theft of QoS while still permitting the user to be root

avani
Download Presentation

Preventing Theft of Quality of Service on Open Platforms

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Preventing Theft of Quality of Service on Open Platforms Kwang-Hyun Baek and Sean W. Smith Department of Computer Science Dartmouth College kwang-hyun.baek@dartmouth.edu

  2. This Talk • Goal: Prevent insider’s theft of QoS while still permitting the user to be root • Motivation: Dartmouth’s plan for traffic convergence • Summary • Overview of threat model and Diffserv • Our solution • Make end nodes trustworthy • Trusted hardware and high assurance OS • Network authentication • Distribute Diffserv classifier and marker to end nodes • Security and performance discussions • Future work

  3. Threat Model • End node user with root account and physical access • Authenticated and authorized • Can install/modify hardware • Can modify network driver, firmware, ROM • Can install/modify software, including kernel • Can modify outgoing packets • Can modify a program’s packet generation • Can use arbitrary port for applications • Can spoof MAC address and IP address

  4. Background: Diffserv • Differentiated Services • At the Ingress/Egress nodes • Classify packets via packet inspection • Meter the temporal state of the packet (i.e., rate) • Mark the packets’ Diffserv Code Point (DSCP) according to its class • Shape the packets (drop or delay) • At other nodes, Per-Hop Behavior (PHB) is applied based on DSCP • Assured Forwarding • Expedited Forwarding • Problem • End nodes are not trusted • Network can gain only limited knowledge

  5. Misbehaving Application Ingress Network Node End Node Class Platinum (Video streaming) layer-3: UDP application: RTP ip set DSCP 46 Hacked File Sharing app Video Streaming Class Best Effort ip set DSCP 0

  6. Misbehaving End Node End Node MAC: 00:00:00:00:00:00 Spoofed MAC: 00:04:00:00:00:00 Ingress Network Node Class Platinum (Priority Client) source MAC 00:04:00:00:00:00 ip set DSCP 46 File Sharing Malware Class Best Effort ip set DSCP 0

  7. Our Solution • Apply trusted computing to QoS • Move Diffserv classifier and marker to each end node • Network’s QoS rule: hash of program binary and DSCP • Use high assurance OS to create a configuration that classifies and marks the packets according to the network’s rule • Use trusted hardware to bind the configuration to authentication secret • If classifying and marking is modified, access to the authentication secret is denied • Accessing the network  classifying and marking according to the network’s QoS rule

  8. Building Block: Trusted Platform Module (TPM) • Designed by Trusted Computing Group (TCG) • Measures the hardware and software configuration of the host • Platform Configuration Registers • Attests the host’s configuration to a remote party • Stores RSA keys • Binds the stored RSA keys to a configuration • Problem • Root can spy on memory used by the TPM • Bound keys need to be changed too often if the configuration includes programs that need frequent updates • Root can change code after the TPM has measured it • Need for high assurance OS with restricted access control and integrity protection

  9. Building Block: High Assurance OS • SELinux Linux Security Module (NSA) • Role-based mandatory access control • Compartmentalization blocks memory spying • Robust access control over devices, memories, files, socket structures • Enforcer LSM (Marchesini, et al) • Makes TPM-bound keys more usable • Long term (hardware, OS, Admin’s public key, SELinux policy) protected by TPM-bound key • Medium term (programs, kernel modules, libraries, linkers) protected by the LSM and Security Admin—a third party who issues signed database of trustworthy applications • Integrity Protection (modification results in TPM lock or kernel panic) • Short term (data, configuration) protected by encrypted file system

  10. Distributed Classifier and Marker • QoS Admin • Issues signed database of program binary’s hash and the DSCP it should receive • Modified LSM • The kernel keeps track of which opened socket belongs to which program (Socket monitor) • The kernel marks each packet’s DSCP at the kernel’s IP layer using Netfilter (standard Linux firewall) hooks, according to the QoS Admin’s signed database (DSCP marker)

  11. Is App X in Security Admin's Policy? Is App X found in QoS Admin's Policy? Socket Monitor App X calls socket syscall NO YES Log and return (will be dropped) YES NO Record socket, h(X), DSCP Record socket, h(X), default DSCP

  12. DSCP Marker Outgoing packet enters IP Layer Is the packet coming from a recorded socket? YES NO Modify the packet's DSCP to the recorded value Drop

  13. Adding Client Authentication • Uses TPM-bound key (EAP-TLS) • EAP-TLS authentication requires the knowledge of the private key • During certification, the CA checks the long term configuration of the host • To access the TPM-bound private key to authenticate itself to the network, an end node must do the following: • Be in the long term configuration to which the key is bound to • Run Enforcer LSM, SELinux, and our socket monitor and DSCP marker • Run valid Security Admin and QoS Admin’s databases (their signature is validated) • SELinux is using a known, trustworthy SELinux policy • Have not modified important medium term configuration

  14. Stopping Misbehaving Application End Node Class Platinum Linphone Gnomemeeting ip set DSCP 46 Hacked File Sharing Linphone (VoIP) Class Best Effort ip set DSCP 0 Class Blacklist Drop

  15. Stopping Misbehaving End Node End Node Hacked Wireless Driver and its firmware to gain better QoS Class Platinum Linphone Gnomemeeting ip set DSCP 46 Configuration mismatch results in TPM lock or kernel panic Cannot access the authentication private key! Class Best Effort ip set DSCP 0 Class Blacklist Drop

  16. Performance evaluation • IBM T40, Pentium M 1.3 GHz, 256 MB • Overhead caused by socket monitor • 4.86 ms average delay for linphone • Overhead caused by DSCP marking • 0.0087 ms average delay for linphone • ITU recommends maximum delay of 150 ms for voice system • The Overhead is easily absorbed

  17. Security Considerations • Forked children inherit sockets • QoS Admin’s job to control the QoS level of the programs that fork and exec other programs • Another option: least privilege principle for shared socket • SELinux should prohibit low-privileged programs from piping packets to high-privileged programs • Hardware spying on TPM • No Plug-and-Play, USB/Firewire devices should be disabled at the kernel level • EAP-TLS results in session keys for encryption and integrity protection • Compartmentalize to block spying on session keys • No man-in-the-middle attack between ingress node and end node

  18. Future Work • Attestable, cleaner, easy-to-understand policies for SELinux • Migratable QoS and Security Admin database • Database version check and automatic update • Boot-time generation of attribute certificate containing the policy version, signed by the TPM-bound key • Quarantined database updating using VLAN • Bigger scale testing • Performance evaluation depending on system loads • Code will be available at http://enforcer.sourceforge.net • Or email me until then for the kernel patch

  19. Thanks • We thank our sponsors—Mellon Foundation, Cisco, Intel, and the Office for Domestic Preparedness (U.S. Dept of Homeland Security)

  20. Questions?

More Related