[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
New security manager for BlueZ.
I though this could interesting for OpenBT folks as well.
Sorry if it's not.
>I got a good news for you. We have pretty much complete support for Bluetooth security level 3 and 1 :).
>Now you should be able to talk to all those fancy Bluetooth phones and stuff that require authentication
>I read Bluetooth specs and some Bluetooth security reviews and I think I understand the process fairly well now.
>So last weekend I implemented missing auth and encrypt stuff and now it's committed to CVS.
>How it works. Basically HCId is the guy :) it implements all security related functionally
>and have to be running in order for auth/encrypt to work. HCId maintains local link_key
>cache (/var/cache/bluetooth/keys) where it stores link keys obtained during pairing.
>Also we have a "PIN helper" which could be a script or a binary or whatever. HCId calls
>PIN helper when it doesn't know which PIN to use. Read below.
>HCId has 2 security modes "auto" and "user". In "auto" mode, /etc/bluetooth/pin is used
>as our local PIN for authenticating incoming connections and PIN helper is used to get a
>PIN for outgoing connections. In "user" mode HCId always calls PIN helper for both incoming
>and outgoing connections.
>"auto" is a default mode and can be used both server and client type of machines. For example
>in case of an access point you set the PIN code in /etc/bluetooth/pin (text file) and all clients
>who want to connect to this access point will have to use that PIN for authentication.
>"user" mode can be used for personal laptops or PDA where user may need a full control
>over both incoming and outgoing connections.
>As I mentioned when HCId doesn't know what PIN code to use it calls PIN helper, an external app
>responsible for providing PIN code to HCId. PIN helper can implement it's own PIN generation policies
>and methods like data base look up, etc. Currently PIN helper is just a Python script that displays window
>on a local X display asking user for a PIN. X window is very simple it tells user whether it's incoming or
>outgoing connection and remote bd address. It allows user to enter a PIN code and to accept or deny the connection.
>I think that this design is very flexible and allows you to customize auth behavior very easily. You can
>implement your own PIN helper that could be just a shell script that looks up a key in some secret file
>or it could send an email to access point administrator and ask him for a PIN code :)
>See bluez/tools/bluepin for PIN helper implementation example.
>HCId has got bunch of new config options that allow you to configure things like PIN helper path, size
>of the link_key cache, enable/disable auth and encrypt on the device, etc. Check out latest hcid.conf in CVS.
>I'll implement config file rereading on SIGHUP soon, so you won't have to restart HCId every time you
>change config file. Also link key cache update policy (replacement of old keys) is not fully implemented yet.
>Please let me know if something doesn't work or if above implementation doesn't cover you use case.
>Any feedback is very welcome.