I want to develop a toolkit applet for UICC. One of the aspects of this development is using SCP80,81 in OTA and handle it in UICC side but, I can't find the specification of SCP80,81 to implement the methods. Please let me know which standard describes this protocol in aspect of implementation.
SCP80
ETSI TS 102 225 [Secured packet structure for UICC based applications;
Release 9]
ETSI TS 102 226 [Remote APDU structure for UICC based applications;
Release 9]
SCP81
GlobalPlatform Card Specification v.2.2 Amendment B: Remote
Application Management over HTTP v1.1.1
I was struggling to find the place where this connection between specifications and numbers (80, 81) is defined.
Here is a quote from the GlobalPlatform Card Specification v2.3.1 section 10.7 Secure Channel Protocol Identifier:
The following values are assigned to the Secure Channel
Protocol identifier:
...
'80' to 'EF' – Reserved for use by individual schemes registered by GlobalPlatform
'80' – Secure Channel Protocol '80' defined in [TS 102 225] and [TS 102 226]
'81' – Secure Channel Protocol '81' defined in [Amd B] based on HTTP and Pre-Shared Key TLS
protocols
[Amd B] is GlobalPlatform Card Specification 2.2 Amendment B
v1.1.3 – RAM over HTTP as defined section 1.3 References of that specification.
Related
As I know, in BLE Secure-Connections Only (SCO) mode, all incoming and outgoing traffic between two paired devices is both authenticated and encrypted. However, BLE also allows to assign individual access permissions to attributes.
Thus, I am wondering whether the BLE specification allows the existence of attributes that neither require authentication nor encryption if two devices are communicating in SCO mode. To give a concrete example: Can device A have an attribute that does not require security and can device B access that attribute without security?
Note that the Secure Connections Only mode is just a high-level "concept" in GAP that doesn't really exist on the ATT/GATT protocol level.
This is all in the spec there is to say about it (Bluetooth Core specification v5.3, Vol 3 Part C (GAP)):
10.2.4 Secure Connections Only mode
A device may be in a Secure Connections Only mode. When in Secure Connections Only mode only security mode 1 level 4 shall be used except for services that only require security mode 1 level 1.
The device shall only accept new outgoing and incoming service level connections for services that require Security Mode 1, Level 4 when the remote device supports LE Secure Connections and authenticated pairing is used.
Mode 1 level 1 means unencrypted, unauthenticated. Mode 1 level 4 means that LE Secure Connections are used with authenticated pairing, i.e. not "LESC Just Works".
So to claim that your device is in SCO mode, you can have a mix of services that don't require any encryption at all and services that only allow to be used when authenticated LESC is used. The services that don't require any encryption can be used at anytime, both when the link is encrypted and when it is unencrypted. The other services can only be used when the connection is encrypted with authenticated LESC.
If I interpret it correctly, you can therefore not have a GATT service with multiple characteristics such that one characteristic is accessable without encryption and one other characteristic is only accessable with encryption. In that case you need to split it up into two services, one without encryption requirements and one with authenticated LESC as requirement.
Anyway, "SCO mode" is just abstract terminology that doesn't have any implications in practice except that it categorises service structures. Basically what you can do with it is to print a label on your product "certified to support SCO mode". It can also be useful as a flag in Bluetooth stacks you can set that validates that the local GATT db fulfills the requirements for SCO.
I am investigating the types of security available in Bluetooth Low Energy (BLE) related to GATT. More specifically, what kind of operations are done when using gatttool with different security levels specified (low, med, high)? My understanding is that the Security Manager in BLE supports 4 different security properties:
no pairing
pairing with an association model that doesn't support man-in-the-middle (MitM) protections (JustWorks)
pairing with MitM protections (passkey entry, numeric comparison, OOB)
LE Secure Connections pairing.
Are these security properties related to the security levels specified with gatttool or is there some other security feature I missed while reading the Bluetooth Specification?
Edit: I would like to extend my question in order to clarify the issue. How does the 4.2 Bluetooth stack determine whether to use legacy pairing or not? That is to say, if I have a packet capture of two BLE 4.2 devices pairing, how can I tell whether legacy pairing is being used vs pairing that uses ECDH? Does the Secure Connections flag indicate that legacy pairing should not be used or is it just its own mode that ensures FIPS approved algorithms are used?
You are correct but you forget one main threat in BLE communication. Here are the three basic threats :
Man In The Middle (MITM) :
A MITM requires an attacker to have the ability to both monitor and alter or inject messages into a communication channel
Eavesdropping :
Passive Eavesdropping is secretly listening (by using a sniffing device) to the private communication of others without consent
Privacy/Identity tracking :
Since most of the Bluetooth LE advertisement and data packets have the source addresses of the devices that are sending the data, third-party devices could associate these addresses to the identity of a user and track the user by that address
The quotes come from developer.bluetooth.org.
You already mentioned the protections against MitM and Eavesdropping, however there is still the problem of identity tracking.
The protection against identity tracking is to use a MAC address that cannot be linked to the same device through time, i.e. a MAC address that changes (typically every 15 minutes). There are four types of MAC address :
Public address : This address is unencrypted and contains your company unique ID and your device ID. It's unsafe since it does not change through time.
Random static address : This address is random (and known as random thanks to flags inside) and unencrypted. Once it does change, you loose the ability to reconnect with the devices that already knows you, you've got to restart the connection from scratch.
Random resolvable private address : This address can be resolved by the devices that know its IRK, a shared secret between the devices. As for the static random address it changes often but is always resolvable. It's the most common option since it preserves privacy and allow to restore a connection.
Random non-resolvable private address : This address cannot be resolved. The Core Spec doesn't say that much about it and it seems not to be very common. The difference with the static address is that it is not stored since it's a private address (i.e. a device doesn't expect to be able to restore a connection with a private address device).
This is explained in BLE Core Spec 4.2 Vol. 3 Part C 15.1.1 Bluetooth Device Address Types.
Concerning the security level, I don't know gatttool but I will assume it's somehow similar to nRF Connect/Master Control Panel or LightBlue. What you see here is probably the security level associated with each attribute. There are four security levels and they can be different for each attribute :
Mode 1 Level 1 :
No encryption required. The attribute is accessible on a plain-text, non-encrypted connection.
Mode 1 Level 2 :
Unauthenticated encryption required. The connection must be encrypted to access this attribute, but the encryption keys do not need to be authenticated (although they can be).
Mode 1 Level 3 :
Authenticated encryption required. The connection must be encrypted with an authenticated key to access this attribute.
Mode 1 Level 4 :
Authenticated LE Secure Connections pairing with encryption. The connection must be encrypted using the Secure Connection Pairing, which was introduced in Bluetooth LE since version 4.2.
The definitions of modes 1 level 1-3 come from 'Getting Started with Bluetooth Low Energy' by Robert Davidson, Akiba, Carles Cufi, Kevin Townsend.
The device can also be in a mode called Secure Connection Only in which all its services, except the one in Mode 1 Level 1, can only be accessed in Mode 1 Level 4.
How does the 4.2 Bluetooth stack determine whether to use legacy pairing or not? That is to say, if I have a packet capture of two BLE 4.2 devices pairing, how can I tell whether legacy pairing is being used vs pairing that uses ECDH? Does the Secure Connections flag indicate that legacy pairing should not be used or is it just its own mode that ensures FIPS approved algorithms are used?
During the pairing feature exchange stage, if the Secure Connections (SC) flag is set in the Pairing Request and Pairing Response PDUs, then LE SC is used. It indicates that both devices support LE SC and agree to use it.
If LE SC is used, the logs will show "Pairing Public Key" and the "Pairing DHKey Check" PDUs being exchanged. These are specific to LE SC.
Yes it's correct but you should note that their are still exists security mode,LE security mode 1 and LE security mode 2, which is combined by different security levels. And before Bluetooth 4.2, LE is not secure i.e. you can sniffer the encrypt key at the just beginning of the LE connection.
I was wondering whether the Host can provide the Link Key to the Controller with BR/EDR Bluetooth, and Bluetooth Low Energy (BLE). (v4.2)
The BT Core Spec v4.2 says:
7.1.10 Link Key Request Reply Command
Command OCF Command Parameters Return Parameters
HCI_Link_Key_Request_Reply 0x000B BD_ADDR, Link_Key Status, BD_ADDR
The Link_Key_Request_Reply command is used to reply to a Link Key
Request event from the Controller, and specifies the Link Key stored
on the Host to be used as the link key for the connection with the
other BR/EDR Controller specified by BD_ADDR. The Link Key Request
event will be generated when the BR/EDR Controller needs a Link Key
for a connection.
Source:
Bluetooth Core Specification v4.2
> Vol 2: Core System Package [BR/EDR Controller volume]
>> Part E: HOST CONTROLLER INTERFACE FUNCTIONAL SPECIFICATION
>>> 7.1.10 Link Key Request Reply Command
It seems to be only valid for BR/EDR (Classic Bluetooth) and not for Low Energy. However, the spec is not very well written and it might be that this part was not updated to imply a compatibility with BLE. Moreover, I can't simply use this command to make the Host send a Link Key to the controller; the controller must send a HCI_Link_Key_Request before.
Hence my question:
Can I make the Host provide the Link Key to the Controller for BR/EDR and BLE?
The HCI command you mentioned is used for BR/EDR. This is used only for authentication after the pairing was successfully done before. so once two devices are paired , on connection depends on the security Mode ( assuming security Mode 4 level 4), does a mutual authentication , This involves the controller asking the Host for the linkkey stored in the host earlier. The HCI command you mentioned is used to supply this linkkey stored in host back to controller. if the host doesn't have a linkkey then the host issues a HCI_Link_Key_Request_Negative_Reply this results in a failure on the initiator with Key or PIN missing error code.
in case of LE HCI_LE_Long_Term_Key_Request_Reply is used for the same purpose.
on your question about whether it is able to provide the linkkey without beeing asked for it , for BR/EDR you can use HCI_Write_Stored_Link_Key, but this is generally not very useful as on turning off bluetooth, the controller forgets the linkkey. on LE there doesn't seem to have an equivalent HCI interface.
Link key cannot be provided by host to controller, on authentication procedure, link key will be generated by controller and send to host(link key is generated using lot of parameters, please check BT Spec)
How to connect VOIP to PSTN? I have read a lot about VOIP to VOIP. But how is it possible to connect VOIP to PSTN? I have tried to search after this information on Google without success.
It depends on type of your PSTN lines. In short, for T1/E1 you can use big carrier-grade gateways, Cisco for example, and for 2-wire POTS lines you can use small phone adapters with FXS/FXO ports, such as Audiocodes or Linksys. They are SIP-based, so you will need to register them as SIP endpoints.
The interworking that you mention is generally performed on a SoftSwitch. These are any to any Signaling protocol conversion. So a very common scenario is what you referred to as VoIP to PSTN or vice versa. I am using SIP to ISUP as a example here.
Usually the PSTN side can be broken to Signaling Gateways and Media Gateways. While the Signaling GW converts the SIP Request / Response to equivalent Signaling message, the SDP is used to control the Media Gateway based on MEGACO or MGCP. For a normal SIP Call these shall be the conversion for the signaling message. Similar rules apply for H323 to PSTN conversion.
INVITE + SDP -> IAM 180 / 183 -> ACM / CPG 200 -> ANM / CON BYE -> REL
You can check RFC 3398 to check some of these SIP to PSTN conversion rules.
There was another mechanism ITU-Q.1912.5 where the entire ASN encoded ISUP Message body is carried as part of the MIME attachment of the SIP Message and then the message is extracted and sent to the SS7 network. This was part of IPX / GSX [Global Switching Exchange] where the messages across long hops shall be carried over VoIP and on its last mile be converted to equivalent ISUP Signaling.
Now if you are only interested in knowing how a SIP UA can be terminated on a Mobile phone you need to have a partnership with one of the VoIP carriers that provide ISUP Termination capabilities. But somewhere in there switching equipment they will be having mechanisms similar to what is explained above.
There are ATA devices that have a VOIP as well as a POTS port and can connect calls between them. Linksys SPA3102 is one such device. These things are extremely configurable and you can have them automatically answer voip calls and provide a PSTN dial tone or automatically call preset phone numbers.
I need to implement a simple probe that uses "open" microsoft rdp protocol. But that protocol refers to x.224 specification and ITU want money in order to download it. Is it any free version of x.224 protocol available?
While I was unable to find a free version of x.224 recommendation RFC1950 states this:
ITU-T Recommendation X.224, Annex D, "Checksum Algorithms,"
November, 1993, pp. 144, 145. (Available from
gopher://info.itu.ch).
ITU-T X.244 is also the same as ISO 8073.
ISO 8073 is available on BANalyzer network protocol database.
I downloaded the RDP spec doc from MS' Open Specifications site, and its reference to the X.224 standard contained a link to a page on the ITU web site that provides a PDF download.
X.244 is not a RDP Protocol, RDP is a MS protocol like ICA used by Citrix.
When you will perform a RDP connection, MS use this protocol to connect to the servers.
I took the sniffing when performing RDP to MS 2003 / 2008 to confirm the same.
39 12:12:56 10.130.35.164 10.130.35.226 X.224 Connection Request (0xe0)
41 12:12:56 10.130.35.226 10.130.35.164 X.224 Connection Confirm (0xd0)
293 12:13:30 10.130.35.164 10.130.35.226 X.224 Connection Request (0xe0)
295 12:13:30 10.130.35.226 10.130.35.164 X.224 Connection Confirm (0xd0)
Hope this helps..
Cheers!!
Dhruv
I'm not sure if it was only recently released but you can find it here: http://www.itu.int/rec/T-REC-X.224-199511-I/en