JABWTandSATSA

JavaBin 18.May2006

AndrN.Klingsheim NoWiresResearchGroup DepartmentofInformatics UniversityofBergen

Outline

Bluetooth JABWT (Java APIs for Bluetooth Wireless Technology) SATSA (Security And Trust Services API)

Bluetooth (I)

Low cost, low power, short range radio technology Ericsson Mobile Communications started developing Bluetooth in 1994 Intended as replacement to cables connecting mobile phones and their accessories Now the Bluetooth SIG (Special Interest Group) is responsible for development of Bluetooth standards

Bluetooth (II)

First Bluetooth devices on market in 1999 Available in many newly released mobile phones, PDAs, laptops Supported on Windows, Linux, OSX... Bluetooth USB dongles are cheap Several specifications exist: 1.0, 1.1, 1.2, 2.0, EDR (Enhanced Data Rate) Bluetooth devices form small ad hoc networks

Bluetooth areas of use

Common use:

Wireless handsfree for mobile phone Synchronize data between mobile device and computer Transfer entries from phone book to other device Vending machine, informational services, door lock systems, multi-user gaming
5

Other scenarios:

Bluetooth functionality

Bluetooth services Device discovery, service search Communication

L2CAP (Logical Link Control and Adaptation Protocol)

Packet oriented Provides error control Uses L2CAP, provides flow control Connection oriented
6

RFCOMM, COM port (RS-232) emulation

Bluetooth security

Authentication

Pairing/bonding Hardware support in Bluetooth module Restrict access to services Trusted devices

Confidentiality (encryption)

Authorization

No integrity check of data packets!

7

Bluetooth profiles

Profiles define higher layer procedures and uniform ways of using the lower layers of Bluetooth Guide developers on how to implement a given end-user functionality New profiles defined by Bluetooth SIG working groups

Profile examples

Generic Access Profile (GAP) Serial Port Profile (SPP) Dial Up Networking Profile (DUNP) FAX Profile Headset Profile Generic Object Exchange Profile (GOEP)

JABWT

JSR-82 Defines two optional packages

javax.bluetooth

Access to Bluetooth functionality OBject EXchange (OBEX) protocol support

javax.obex

Most JABWT enabled devices include only the javax.bluetooth package A few newly released devices also include javax.obex 10

javax.bluetooth

Gives access to local Bluetooth device through LocalDevice Represents and interacts with remote device with RemoteDevice Provides device and service search with DiscoveryAgent Represents service as ServiceRecord Uses GCF to set up Bluetooth connections
11

Order of operations

Usual order of operations for client

Discover service

1. Search for other Bluetooth devices 2. Search for wanted service on discovered devices 3. Connect to service on selected client

If service discovered earlier, do step 3 only

Usual order of operations for server

1. Create service 2. Serve clients
12

JABWT communication

Both L2CAP and RFCOMM connections are supported RFCOMM is recommended

Flow control provided Provided through Serial Port Profile Easy to use

13

SATSA

Security And Trust Services API (JSR-177) Defines four optional packages

SATSA-APDU (Application Protocol Data Unit) SATSA-JCRMI (Java Card Remote Method Invocation protocol) SATSA-PKI (Public Key Infrastructure) SATSA-CRYPTO Implemented in hardware or software Performs cryptographic operations
14

Defines Security Element (SE)

Smart card packages

SATSA-APDU

Smart card communication using APDU defined in the ISO7816-4 specification Low level communication Communication with JavaCards High level communication with smart cards

SATSA-JCRMI

15

SATSA-PKI (I)

X.509 client certificate management

Generate Certificate Signing Request (CSR)

SE generates public/private keypair

Maintain certificate store with user certificates

User can add/delete certificates (by an identifier) User cannot retrieve a representation of a certificate

16

SATSA-PKI (II)

SE generates digital signatures

SATSA seizes control of the user interface

User selects which certificate to use User is shown data about to be signed Signature is handed over to application

Private key is never exposed to application Signed data is on the Cryptographic Message Syntax (CMS) format Recommended signature algorithm: SHA1withRSA
17

SATSA-CRYPTO

SE verifies digital signature

Application provides data, signature and public key

Message digests (recommended SHA-1) SE performs encryption

Asymmetric ciphers (recommended RSA) Symmetric ciphers (recommended DES, 3DES, and AES) Application provides data and encryption key
18

All computations are carried out by SE

Some difficulties (I)

Signature generation is easy Signature verification is harder

Signed data must be parsed and split into data and signature parts Public key must be read from certificate Signer's certificate must be validated

19

Some difficulties (II)

Encryption/Decryption

Application must provide both data and encryption key Private keys in SE can only be used by SE to sign data Application must handle key generation, and secure storage of encryption keys

20

Solution (I)

Application must handle:

Storage of own user certificates

So they can be shared with communicating parties To validate own signatures

Storage of communicating parties' certificates

To validate signatures To encrypt data with asymmetric ciphers To decrypt data with asymmetric ciphers
21

Storage of own private key

Solution (II)

Storage of symmetric keys

To encrypt/decrypt data with symmetric ciphers To confirm signer's identity To confirm that a certificate is valid

Certificate parsing and validation

22

Links

http://wireless.klings.org http://wap.klings.org http://www.jcp.org/en/jsr/detail?id=82 http://www.jcp.org/en/jsr/detail?id=177

23