A first Demonstrator for a CAHN infrastructure Bluetooth in CAHN

Reminder on Bluetooth Security Bluetooth provides three Security Modes: No Security Authentication Authentication and Encryption Authentication is based on a PIN Encryption is based on encryption keys, which are derived from the link key, which in turn is based on the PIN

The Bootstrapping Problem How can a PIN between two entities be defined, when the entities do neither know each other nor see each other? A Service Provider can sell PINs (Pre Paid Solution, Authorization, not Authentication) A third Entity can provide PINs on demand for registered users (all users have to have a subscription with this third party, which provides a higher level authentication) Our suggestion: CAHN

How CAHN can help to get a PIN The Scenario Service Connection Request Service Connection Response, including the PIN Secure Connection

Bluetooth Goodies Inquiries Helps to find other devices in vicinity Service Discovery Helps to find services on a given device in vicinity Profiles Services are well defined by Profiles

Example: PAN Profile, Network Access Point Service Name: Network Access Point Service RecHandle: 0x804ccf0 Service Class ID List: "Network access point" (0x1116) Protocol Descriptor List: "L2CAP" (0x0100) PSM: 15 "BNEP" (0x000f) Version: 0x0100 SEQ16: Profile Descriptor List: "PAN access point" (0x1116) Version: 0x0100

New Profile: CAHN Is it possible to create a new Profile for CAHN The goal of the Profile would be to find out which devices are able to “speak” CAHN MSISDN as Attribute

The Scenario with Service Discovery 12:34:56:78:9a:bc

The Scenario with Service Discovery 12:34:56:78:9a:bc Service Browse Request Service Browse Response MSISDN

The Scenario with Service Discovery 12:34:56:78:9a:bc Connection Request Link Key Request MSISDN Link Key Negative Response PIN Request PIN Negative Response Connection Negative Response

The Scenario with Service Discovery 12:34:56:78:9a:bc MSISDN Service Connection Request Processes Request (AC) Generates a PIN Sends back a Response

The Scenario with Service Discovery 12:34:56:78:9a:bc MSISDN PIN Service Connection Response (incl. PIN) Connection Request Link Key Request Link Key Negative Response PIN Request PIN Positive Response Connection Positive Response

Implementation – Flow Chart WLANBLTCellular USSDSMS CAHN Communication Module (CCM) Het. VPNFile Transfer GUI Key Management CAHN Protocol via Cellular

CAHN Communication Module (CCM) Responsible to treat Requests and Responses and to handle the Bluetooth Connector or the Cellular Adapter Daemon waiting for Requests Provides a socket interface to the Cellular Adapter (local, multiplexed UNIX socket)

Cellular Adapter Translates packets from the CCM to Cellular packets and vice versa Communicates with the local CCM via a socket interface Communicates with the Cellular with help of the gsmlib and a serial connection to a cell phone

Bluetooth Connector Is invoked by the CCM Responsible for Access Control PIN Generation Service Configuration PIN Database (MySQL) (Billing Records)

Consists of three messages CAHN Bluetooth Service Request CAHN Bluetooth Service Response Error Message CAHN Protocol PDU_IDP_LENSRC_MSISDNDST_MSISDNSRC_BADST_BABluetooth Service ID HDRCAHN HDRBLT HDRSVC DATA PDU_IDP_LENSRC_MSISDNDST_MSISDNSRC_BADST_BABluetooth Service ID HDRCAHN HDRBLT HDRSVC DATA PIN PDU_IDP_LENSRC_MSISDNDST_MSISDNSRC_BADST_BAError Code HDRCAHN HDRBLT HDRSVC DATA (Optional)

Open Issues Bluetooth related Can this really be a Profile? Creation of a UUID Attributes Standardization through Bluetooth SIG Cellular related Transport Mechanism (USSD, GPRS or SMS?) Architecture Realization (Java?) General GUI Definition of Interfaces between the different modules Further Protocol Definition Access Control PIN Generation by the Operator

Thank you! Questions? Suggestions?