<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://devzone.nordicsemi.com/cfs-file/__key/system/syndication/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>How is the LESC OOB data generated?</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/64121/how-is-the-lesc-oob-data-generated</link><description>The OOB data for LESC pairing contains the BLE GAP Address 256bit random and 256bit confirm value, and is generated by sd_ble_gap_lesc_oob_data_get using the connection handle and public key. sd_ble_gap_lesc_oob_data_set sets the OOB data when the BLE_GAP_EVT_LESC_DHKEY_REQUEST</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Wed, 29 Jul 2020 05:45:35 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/64121/how-is-the-lesc-oob-data-generated" /><item><title>RE: How is the LESC OOB data generated?</title><link>https://devzone.nordicsemi.com/thread/262089?ContentTypeID=1</link><pubDate>Wed, 29 Jul 2020 05:45:35 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:c2276f50-d315-47cd-b25f-39383acf0079</guid><dc:creator>raccoon</dc:creator><description>&lt;p&gt;The content of the OOB data is spec defined,&lt;br /&gt; so let&amp;#39;s assume that you simply want to know how OOB data is generated according to the spec.&lt;br /&gt;&lt;br /&gt;By changing 2 Bytes - even on both sides - it is quite natural that you fail the pairing.&lt;br /&gt;Have a look at the spec and notice that the confirmation value is a computed value.&lt;br /&gt;It is something that peers compute on their own and then simply compare to what they received in the OOB data.&lt;/p&gt;
&lt;p&gt;&lt;/p&gt;
&lt;p&gt;Have a look a the following python snippet I used once upon a time to understand on my own the OOB data:&lt;br /&gt;&lt;br /&gt;&lt;pre class="ui-code" data-mode="python"&gt;from Crypto.Random import get_random_bytes
from Crypto.Hash import CMAC
from Crypto.Cipher import AES
from Crypto.PublicKey import ECC

&amp;quot;&amp;quot;&amp;quot;
From v5.1 Vol 3 - Part H - Section 2.2.6
The confirm value generation function makes use of the MAC function AES-CMAC_X, 
with a 128-bit key X.

The inputs to function f4 are:
- U is 256 bits
- V is 256 bits
- Z is 8 bits.
  For Numeric Comparison and OOB protocol - all zeros.
- X is 128 bits

U, V and Z are concatenated and used as input m to the function AES-CMAC.
X is used as the key k.

f4(U, V, X, Z) = AES-CMAC_X(U||V||Z)

The inputs to f4 are different depending on different association models.
For OOB f4(PKx, PKx, r, 0) where r is a random value.
&amp;quot;&amp;quot;&amp;quot;

key = ECC.generate(curve=&amp;#39;P-256&amp;#39;)
PKx = key.public_key()._point.x.to_bytes()
Z = b&amp;#39;\x00\x00\x00\x00\x00\x00\x00\x00&amp;#39;
r = get_random_bytes(16)

cobj = CMAC.new(r, ciphermod=AES)
cobj.update(PKx + PKx + Z)


print(f&amp;#39;For your reference, this is the private key: {key.d.to_bytes().hex()}&amp;#39;)
print(f&amp;#39;OOB: PKx: {PKx.hex()}&amp;#39;)
print(f&amp;#39;OOB: PKy: {key.public_key()._point.y.to_bytes().hex()}&amp;#39;)
print(f&amp;#39;OOB: r: {r.hex()}&amp;#39;)
print(f&amp;#39;OOB: Confirmation: {cobj.hexdigest()}&amp;#39;)
&lt;/pre&gt;&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: How is the LESC OOB data generated?</title><link>https://devzone.nordicsemi.com/thread/261588?ContentTypeID=1</link><pubDate>Fri, 24 Jul 2020 11:54:37 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:48e9814f-e10a-455f-ae44-c8267b10a0f6</guid><dc:creator>&amp;#216;yvind</dc:creator><description>&lt;p&gt;&lt;span&gt;Hello,&amp;nbsp;&lt;/span&gt;&lt;br /&gt;&lt;br /&gt;&lt;span&gt;The technical support team is currently understaffed and have too many support tickets to handle. We expect a more normal function on Monday, and I will have a look at your case then.&amp;nbsp;&lt;/span&gt;&lt;br /&gt;&lt;br /&gt;&lt;span&gt;I&amp;#39;m sorry for the inconvenience this may cause.&amp;nbsp;&lt;/span&gt;&lt;br /&gt;&lt;br /&gt;&lt;span&gt;Kind regards,&lt;/span&gt;&lt;br /&gt;&lt;span&gt;Øyvind&lt;/span&gt;&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>