Symbian OS Communications (779884), страница 23
Текст из файла (страница 23)
The RComm classpresents a serial port abstraction to an application; therefore any application using the RComm interface can use a virtual Bluetooth serial port.Ironically, if emulated serial port signals are required, it is actuallybetter to use the RSocket class rather then RComm. This is becausethe Bluetooth implementation of RComm does not map the RComm callsrelating to many of the RS-232 lines onto RFCOMM.
In contrast, a client ofthe RSocket can make RSocket::Ioctl() calls to send and receiveemulated RS-232 signals. Thus the RComm interface to RFCOMM is notrecommended for any new code.Additionally, as mentioned in section 4.1.7, the use of emulated RS232 signals for application-level flow control does not work particularlywell over the asynchronous Bluetooth link, due to the higher latencies and data rates involved. One of its major limitations is that itdoes not support, in the standard Symbian OS release, DCE mode – soincoming connections are not supported on the RComm interface. Therefore we will concentrate on using RFCOMM through the RSocket orCBluetoothSocket interfaces.RFCOMM sockets have different semantics to L2CAP sockets becausethey possess a stream interface – this can simplify the sending and receiving of data as the client does not need to know the size of the underlyingframes RFCOMM uses to exchange data, however, if the protocol beingtransmitted over the RFCOMM channel is frame-based, it does requirethat protocol to implement its own framing scheme.4.2.7 Using Bluetooth socketsBluetooth sockets are exposed through the RSocket API – however, aspecialized Bluetooth wrapper, CBluetoothSocket – exists to makeusing Bluetooth sockets easier.
The latter is described more fully later,but this section describes the generic properties of using sockets forBluetooth.1111The use of a socket-like interface for applications allows the state machines of therelevant protocol (L2CAP and RFCOMM for Bluetooth, but also other protocols in SymbianOS) to be hidden away from the application.
This contrasts with some other implementationsof Bluetooth in the embedded market which provide ‘service interfaces’ to applications: thisBLUETOOTH IN SYMBIAN OS97One small disadvantage of the RSocket API is that it cannot deliverunsolicited protocol indications from the protocol to the application.The most important of these would be a disconnection indication forconnection-oriented protocols (such as L2CAP and RFCOMM) – instead,the indication is provided next time the application performs an operationon the socket. CBluetoothSocket, being a wrapper over RSocket,can provide this service using an internal API – the indications are thendelivered through an M-class implemented by the application.Having said this, applications using RSocket directly will find anyoutstanding operation on a socket such as a write, read or ioctl iscompleted with the system-wide error code of KErrDisconnected, orthe Bluetooth error of KErrHCILinkDisconnection if the channelused by the RSocket is disconnected.
In practice, since applicationswill normally maintain an outstanding read on a socket, this means thedifference in notification between CBluetoothSocket and RSocketis merely a matter of convenience.Socket addresses in Bluetooth are represented by TBTSockAddr. Itextends the basic TSockAddr, described in Chapter 3, with a Bluetoothdevice address and Bluetooth security settings.Derived from TBTSockAddr are TL2CAPSockAddr and TRfcommSockAddr. These two classes really only provide typing and castingfunctionality (although TL2CAPSockAddr adds another port setter/getterwhich can be treated just like those in TSockAddr).Bluetooth SecuritySecurity is obviously a very important part of using Bluetooth – whenwriting an Bluetooth service, you need to give some thought to yoursecurity requirements.
The Bluetooth stack is informed of your security requirements in the form of a TBTSecuritySettings parameterpassed to the TBTSockAddr. TBTSecuritySettings encapsulatesyour service’s security requirements – such as the need for authentication and encryption – and is used by the Bluetooth stack to apply therequested settings at the appropriate stage of an incoming or outgoingconnection.For those of you interested in the relationship between security asspecified in the Generic Access Profile, and that used on Symbian OS,you may be interested to know that Symbian OS operates in securitymode 2.
For those of you for whom that last sentence made no sense,this means that security requirements such as authorization (i.e., userprompting), authentication (i.e., the process of entering a passkey whenimplies that each application which, for example, required an L2CAP connection wouldneed to be aware of the L2CAP state machine in the L2CAP specification. This considerabletask is not required for application developers using Symbian OS.98BLUETOOTHFigure 4.9S60 and UIQ authorization dialogsfirst introducing devices to each other) and encryption are specified on aper-service basis.12 In practice, this means on a per socket basis.Careful thought needs to be given to balance usability and security foreach service. Both the typical use case and the malicious use case need tobe considered.
Typically, in order to defend against malicious use of theservice, the very minimum a service should do is request authorizationfor incoming connections. This gives the user the ability to easily rejectunexpected connections as a simple ‘yes/no’ dialog box is presented, asshown in Figure 4.9 (note though that many users will press ‘yes’ justout of curiosity!).
The key issue to consider here is that the device namecannot be trusted as an indication of the source of the connection,13 since12The specification also defines security mode 1 (no security) and security mode 3(security applied when link created). Security mode 1 is obviously too limiting for a devicethat might run numerous services, each of which will have its own security requirements.Security mode 3 causes problems with usability – it forces users to go through the pairingprocedure before allowing a device to perform an SDP query. This can mean that the usersperform the pairing procedure only to discover that the service they want to use is notavailable. Security mode 2 is a reasonable compromise – users know whether a particularservice is supported or not before having to perform any security procedures, but individualservices can specify their own security requirements.
The security risk that is created bysecurity mode 2 is that everyone (including potential attackers) can discover what servicesare available on your device, however, the increased usability of this option versus theslight trade off in security means that it is a reasonable choice.13A slightly different dialog is presented if the devices have been paired (and cantherefore authenticate each other), indicating that the device connecting is a paired device,which means the name could be trusted.
However, the difference is subtle – the addition ofthe text ‘paired device’ before the device name. Our opinion is that each service should notrely on the user understanding this subtle difference between the two possible prompts – andBLUETOOTH IN SYMBIAN OS99it’s easy to set a device name to whatever you like – thus if you need toensure the connection really is coming from a specific device, use theauthentication service described in the next paragraph.For more sensitive services, such as the ability to send text messagesor use some other billable service on the phone, it is recommendedthat authentication also be required for incoming connections. This willrequire the user to go through a pairing process, involving enteringthe same passkey on both devices, to ensure that the two devices areconnected to each other and not via some untrusted third party (theclassic man-in-the-middle attack).
The dialog used for this is shown inFigure 4.10.Finally, if the data being transferred is in any way sensitive, then it isrecommended that encryption is turned on.For outbound services, it often makes little sense to use authorization, as in most cases the user has just performed some operation thattriggers the underlying use of Bluetooth. Thus authorization is a form of‘are you really sure?’ question. The problem with these dialogs is thatthey condition the user into pressing ‘yes’ without considering the question – training the user into this behavior can reduce security significantly,as when the question being asked is actually important they automaticallyFigure 4.10 S60 and UIQ passkey dialogstherefore if it is important to an application to ensure the connection is coming from aparticular source, rather than another device potentially masquerading as that source, thenit should set the authentication flag on its security settings.
Without this the security burdenis shifted to the user, who is in a far worse position to understand all the implications ofBluetooth security, pairing and accepting connections from unauthenticated devices thanyou are!100BLUETOOTHhit ‘yes’ anyway! It could be argued that outgoing authorization preventsrogue applications creating connections without the user’s knowledge.However, this argument has two flaws – firstly, since it is the applicationthat decides the security settings, then this is easy to bypass – rogue applications simply do not use authorization! Secondly, policing the creationof connections is a role is best left to the Symbian OS platform securitymodel, as this is explicitly designed to restrict this ability to applicationswith the LocalServices capability.Authentication and encryption on outbound services are more interesting.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
