Repository: incubator-mynewt-site Updated Branches: refs/heads/asf-site ac426b0ae -> b435bead2
some minor changes to ble_sec.md Project: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/repo Commit: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/commit/b435bead Tree: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/tree/b435bead Diff: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/diff/b435bead Branch: refs/heads/asf-site Commit: b435bead2e7cb546edcbf1d633545e93d4616a26 Parents: ac426b0 Author: aditihilbert <[email protected]> Authored: Wed Jan 25 18:30:26 2017 -0800 Committer: aditihilbert <[email protected]> Committed: Wed Jan 25 18:30:26 2017 -0800 ---------------------------------------------------------------------- develop/mkdocs/search_index.json | 4 ++-- develop/network/ble/ble_sec/index.html | 3 +-- latest/mkdocs/search_index.json | 4 ++-- latest/network/ble/ble_sec/index.html | 3 +-- mkdocs/search_index.json | 6 +++--- network/ble/ble_sec/index.html | 6 +++--- 6 files changed, 12 insertions(+), 14 deletions(-) ---------------------------------------------------------------------- http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/b435bead/develop/mkdocs/search_index.json ---------------------------------------------------------------------- diff --git a/develop/mkdocs/search_index.json b/develop/mkdocs/search_index.json index c4da28c..e28a9d0 100644 --- a/develop/mkdocs/search_index.json +++ b/develop/mkdocs/search_index.json @@ -7897,7 +7897,7 @@ }, { "location": "/network/ble/ble_sec/", - "text": "BLE Security\n\n\nThe Bluetooth Low Energy security model includes five distinct security concepts as listed below. For detailed specifications, see BLUETOOTH SPECIFICATION Version 4.2 [Vol 1, Part A].\n\n\n\n\n\n\nPairing\n: The process for creating one or more shared secret keys. In LE a single link key is generated by combining contributions from each device into a link key used during pairing. \n\n\n\n\n\n\nBonding\n: The act of storing the keys created during pairing for use in subsequent connections in order to form a trusted device pair. \n\n\n\n\n\n\nDevice authentication\n: Verification that the two devices have the same keys (verify device identity)\n\n\n\n\n\n\nEncryption\n: Keeps message confidential. Encryption in Bluetooth LE uses AES-CCM cryptography and is performed in the \nController\n.\n\n\n\n\n\n\nMessage integrity\n: Protects against message forgeries.\n\n\n\n\n\n\nBluetooth LE uses four association models depending on the I/O capabilities o f the devices. \n\n\n\n\n\n\nJust Works\n: designed for scenarios where at least one of the devices does not have a display capable of displaying a six digit number nor does it have a keyboard capable of entering six decimal digits.\n\n\n\n\n\n\nNumeric Comparison\n: designed for scenarios where both devices are capable of displaying a six digit number and both are capable of having the user enter \"yes\" or \"no\". A good example of this model is the cell phone / PC scenario.\n\n\n\n\n\n\nOut of Band\n: designed for scenarios where an Out of Band mechanism is used to both discover the devices as well as to exchange or transfer cryptographic numbers used in the pairing process.\n\n\n\n\n\n\nPasskey Entry\n: designed for the scenario where one device has input capability but does not have the capability to display six digits and the other device has output capabilities. A good example of this model is the PC and keyboard scenario.\n\n\n\n\n\n\nKey Generation\n\n\nKey generation for a ll purposes in Bluetooth LE is performed by the \nHost\n on each LE device independent of any other LE device. \n\n\nPrivacy Feature\n\n\nBluetooth LE supports an optional feature during connection mode and connection procedures that reduces the ability to track a LE device over a period of time by changing the Bluetooth device address on a frequent basis. \n\n\nThere are two variants of the privacy feature. \n\n\n\n\nIn the first variant, private addresses are resolved and generated by the \nHost\n.\n\n\nIn the second variant, private addresses are resolved and generated by the \nController\n without involving the Host after the Host provides the Controller device identity information. The Host may provide the Controller with a complete resolving list or a subset of the resolving list.\nDevice filtering becomes possible in the second variant when address resolution is performed in the Controller because the peer\u2019s device identity address can be resolved prior to checking wheth er it is in the white list.\n\n\n\n\nNote\n: When address resolution is performed exclusively in the Host, a device may experience increased power consumption because device filtering must be disabled.\n\n\nFor more details on the privacy feature, refer to BLUETOOTH SPECIFICATION Version 4.2 [Vol 3, Part C] (Published 02 December 2014), Page 592.", + "text": "BLE Security\n\n\nThe Bluetooth Low Energy security model includes five distinct security concepts as listed below. For detailed specifications, see BLUETOOTH SPECIFICATION Version 4.2 [Vol 1, Part A].\n\n\n\n\n\n\nPairing\n: The process for creating one or more shared secret keys. In LE a single link key is generated by combining contributions from each device into a link key used during pairing. \n\n\n\n\n\n\nBonding\n: The act of storing the keys created during pairing for use in subsequent connections in order to form a trusted device pair. \n\n\n\n\n\n\nDevice authentication\n: Verification that the two devices have the same keys (verify device identity)\n\n\n\n\n\n\nEncryption\n: Keeps message confidential. Encryption in Bluetooth LE uses AES-CCM cryptography and is performed in the \nController\n.\n\n\n\n\n\n\nMessage integrity\n: Protects against message forgeries.\n\n\n\n\n\n\nBluetooth LE uses four association models depending on the I/O capabilities o f the devices. \n\n\n\n\n\n\nJust Works\n: designed for scenarios where at least one of the devices does not have a display capable of displaying a six digit number nor does it have a keyboard capable of entering six decimal digits.\n\n\n\n\n\n\nNumeric Comparison\n: designed for scenarios where both devices are capable of displaying a six digit number and both are capable of having the user enter \"yes\" or \"no\". A good example of this model is the cell phone / PC scenario.\n\n\n\n\n\n\nOut of Band\n: designed for scenarios where an Out of Band mechanism is used to both discover the devices as well as to exchange or transfer cryptographic numbers used in the pairing process.\n\n\n\n\n\n\nPasskey Entry\n: designed for the scenario where one device has input capability but does not have the capability to display six digits and the other device has output capabilities. A good example of this model is the PC and keyboard scenario.\n\n\n\n\n\n\nKey Generation\n\n\nKey generation for a ll purposes in Bluetooth LE is performed by the \nHost\n on each LE device independent of any other LE device. \n\n\nPrivacy Feature\n\n\nBluetooth LE supports an optional feature during connection mode and connection procedures that reduces the ability to track a LE device over a period of time by changing the Bluetooth device address on a frequent basis. \n\n\nThere are two variants of the privacy feature. \n\n\n\n\nIn the first variant, private addresses are resolved and generated by the \nHost\n.\n\n\nIn the second variant, private addresses are resolved and generated by the \nController\n without involving the Host after the Host provides the Controller device identity information. The Host may provide the Controller with a complete resolving list or a subset of the resolving list.\nDevice filtering becomes possible in the second variant when address resolution is performed in the Controller because the peer\u2019s device identity address can be resolved prior to checking wheth er it is in the white list.\n\n\n\n\nNote\n: When address resolution is performed exclusively in the Host, a device may experience increased power consumption because device filtering must be disabled. For more details on the privacy feature, refer to BLUETOOTH SPECIFICATION Version 4.2 [Vol 3, Part C] (Published 02 December 2014), Page 592.", "title": "NimBLE Security" }, { @@ -7912,7 +7912,7 @@ }, { "location": "/network/ble/ble_sec/#privacy-feature", - "text": "Bluetooth LE supports an optional feature during connection mode and connection procedures that reduces the ability to track a LE device over a period of time by changing the Bluetooth device address on a frequent basis. There are two variants of the privacy feature. In the first variant, private addresses are resolved and generated by the Host . In the second variant, private addresses are resolved and generated by the Controller without involving the Host after the Host provides the Controller device identity information. The Host may provide the Controller with a complete resolving list or a subset of the resolving list.\nDevice filtering becomes possible in the second variant when address resolution is performed in the Controller because the peer\u2019s device identity address can be resolved prior to checking whether it is in the white list. Note : When address resolution is performed exclusively in the Host, a device may experience increased pow er consumption because device filtering must be disabled. For more details on the privacy feature, refer to BLUETOOTH SPECIFICATION Version 4.2 [Vol 3, Part C] (Published 02 December 2014), Page 592.", + "text": "Bluetooth LE supports an optional feature during connection mode and connection procedures that reduces the ability to track a LE device over a period of time by changing the Bluetooth device address on a frequent basis. There are two variants of the privacy feature. In the first variant, private addresses are resolved and generated by the Host . In the second variant, private addresses are resolved and generated by the Controller without involving the Host after the Host provides the Controller device identity information. The Host may provide the Controller with a complete resolving list or a subset of the resolving list.\nDevice filtering becomes possible in the second variant when address resolution is performed in the Controller because the peer\u2019s device identity address can be resolved prior to checking whether it is in the white list. Note : When address resolution is performed exclusively in the Host, a device may experience increased pow er consumption because device filtering must be disabled. For more details on the privacy feature, refer to BLUETOOTH SPECIFICATION Version 4.2 [Vol 3, Part C] (Published 02 December 2014), Page 592.", "title": "Privacy Feature" }, { http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/b435bead/develop/network/ble/ble_sec/index.html ---------------------------------------------------------------------- diff --git a/develop/network/ble/ble_sec/index.html b/develop/network/ble/ble_sec/index.html index f6efbf5..018214f 100644 --- a/develop/network/ble/ble_sec/index.html +++ b/develop/network/ble/ble_sec/index.html @@ -425,8 +425,7 @@ <li>In the second variant, private addresses are resolved and generated by the <em>Controller</em> without involving the Host after the Host provides the Controller device identity information. The Host may provide the Controller with a complete resolving list or a subset of the resolving list. Device filtering becomes possible in the second variant when address resolution is performed in the Controller because the peerâs device identity address can be resolved prior to checking whether it is in the white list.</li> </ul> -<p><strong>Note</strong>: When address resolution is performed exclusively in the Host, a device may experience increased power consumption because device filtering must be disabled.</p> -<p>For more details on the privacy feature, refer to BLUETOOTH SPECIFICATION Version 4.2 [Vol 3, Part C] (Published 02 December 2014), Page 592.</p> +<p><strong>Note</strong>: When address resolution is performed exclusively in the Host, a device may experience increased power consumption because device filtering must be disabled. For more details on the privacy feature, refer to BLUETOOTH SPECIFICATION Version 4.2 [Vol 3, Part C] (Published 02 December 2014), Page 592.</p> <div class="row"> http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/b435bead/latest/mkdocs/search_index.json ---------------------------------------------------------------------- diff --git a/latest/mkdocs/search_index.json b/latest/mkdocs/search_index.json index c4da28c..e28a9d0 100644 --- a/latest/mkdocs/search_index.json +++ b/latest/mkdocs/search_index.json @@ -7897,7 +7897,7 @@ }, { "location": "/network/ble/ble_sec/", - "text": "BLE Security\n\n\nThe Bluetooth Low Energy security model includes five distinct security concepts as listed below. For detailed specifications, see BLUETOOTH SPECIFICATION Version 4.2 [Vol 1, Part A].\n\n\n\n\n\n\nPairing\n: The process for creating one or more shared secret keys. In LE a single link key is generated by combining contributions from each device into a link key used during pairing. \n\n\n\n\n\n\nBonding\n: The act of storing the keys created during pairing for use in subsequent connections in order to form a trusted device pair. \n\n\n\n\n\n\nDevice authentication\n: Verification that the two devices have the same keys (verify device identity)\n\n\n\n\n\n\nEncryption\n: Keeps message confidential. Encryption in Bluetooth LE uses AES-CCM cryptography and is performed in the \nController\n.\n\n\n\n\n\n\nMessage integrity\n: Protects against message forgeries.\n\n\n\n\n\n\nBluetooth LE uses four association models depending on the I/O capabilities o f the devices. \n\n\n\n\n\n\nJust Works\n: designed for scenarios where at least one of the devices does not have a display capable of displaying a six digit number nor does it have a keyboard capable of entering six decimal digits.\n\n\n\n\n\n\nNumeric Comparison\n: designed for scenarios where both devices are capable of displaying a six digit number and both are capable of having the user enter \"yes\" or \"no\". A good example of this model is the cell phone / PC scenario.\n\n\n\n\n\n\nOut of Band\n: designed for scenarios where an Out of Band mechanism is used to both discover the devices as well as to exchange or transfer cryptographic numbers used in the pairing process.\n\n\n\n\n\n\nPasskey Entry\n: designed for the scenario where one device has input capability but does not have the capability to display six digits and the other device has output capabilities. A good example of this model is the PC and keyboard scenario.\n\n\n\n\n\n\nKey Generation\n\n\nKey generation for a ll purposes in Bluetooth LE is performed by the \nHost\n on each LE device independent of any other LE device. \n\n\nPrivacy Feature\n\n\nBluetooth LE supports an optional feature during connection mode and connection procedures that reduces the ability to track a LE device over a period of time by changing the Bluetooth device address on a frequent basis. \n\n\nThere are two variants of the privacy feature. \n\n\n\n\nIn the first variant, private addresses are resolved and generated by the \nHost\n.\n\n\nIn the second variant, private addresses are resolved and generated by the \nController\n without involving the Host after the Host provides the Controller device identity information. The Host may provide the Controller with a complete resolving list or a subset of the resolving list.\nDevice filtering becomes possible in the second variant when address resolution is performed in the Controller because the peer\u2019s device identity address can be resolved prior to checking wheth er it is in the white list.\n\n\n\n\nNote\n: When address resolution is performed exclusively in the Host, a device may experience increased power consumption because device filtering must be disabled.\n\n\nFor more details on the privacy feature, refer to BLUETOOTH SPECIFICATION Version 4.2 [Vol 3, Part C] (Published 02 December 2014), Page 592.", + "text": "BLE Security\n\n\nThe Bluetooth Low Energy security model includes five distinct security concepts as listed below. For detailed specifications, see BLUETOOTH SPECIFICATION Version 4.2 [Vol 1, Part A].\n\n\n\n\n\n\nPairing\n: The process for creating one or more shared secret keys. In LE a single link key is generated by combining contributions from each device into a link key used during pairing. \n\n\n\n\n\n\nBonding\n: The act of storing the keys created during pairing for use in subsequent connections in order to form a trusted device pair. \n\n\n\n\n\n\nDevice authentication\n: Verification that the two devices have the same keys (verify device identity)\n\n\n\n\n\n\nEncryption\n: Keeps message confidential. Encryption in Bluetooth LE uses AES-CCM cryptography and is performed in the \nController\n.\n\n\n\n\n\n\nMessage integrity\n: Protects against message forgeries.\n\n\n\n\n\n\nBluetooth LE uses four association models depending on the I/O capabilities o f the devices. \n\n\n\n\n\n\nJust Works\n: designed for scenarios where at least one of the devices does not have a display capable of displaying a six digit number nor does it have a keyboard capable of entering six decimal digits.\n\n\n\n\n\n\nNumeric Comparison\n: designed for scenarios where both devices are capable of displaying a six digit number and both are capable of having the user enter \"yes\" or \"no\". A good example of this model is the cell phone / PC scenario.\n\n\n\n\n\n\nOut of Band\n: designed for scenarios where an Out of Band mechanism is used to both discover the devices as well as to exchange or transfer cryptographic numbers used in the pairing process.\n\n\n\n\n\n\nPasskey Entry\n: designed for the scenario where one device has input capability but does not have the capability to display six digits and the other device has output capabilities. A good example of this model is the PC and keyboard scenario.\n\n\n\n\n\n\nKey Generation\n\n\nKey generation for a ll purposes in Bluetooth LE is performed by the \nHost\n on each LE device independent of any other LE device. \n\n\nPrivacy Feature\n\n\nBluetooth LE supports an optional feature during connection mode and connection procedures that reduces the ability to track a LE device over a period of time by changing the Bluetooth device address on a frequent basis. \n\n\nThere are two variants of the privacy feature. \n\n\n\n\nIn the first variant, private addresses are resolved and generated by the \nHost\n.\n\n\nIn the second variant, private addresses are resolved and generated by the \nController\n without involving the Host after the Host provides the Controller device identity information. The Host may provide the Controller with a complete resolving list or a subset of the resolving list.\nDevice filtering becomes possible in the second variant when address resolution is performed in the Controller because the peer\u2019s device identity address can be resolved prior to checking wheth er it is in the white list.\n\n\n\n\nNote\n: When address resolution is performed exclusively in the Host, a device may experience increased power consumption because device filtering must be disabled. For more details on the privacy feature, refer to BLUETOOTH SPECIFICATION Version 4.2 [Vol 3, Part C] (Published 02 December 2014), Page 592.", "title": "NimBLE Security" }, { @@ -7912,7 +7912,7 @@ }, { "location": "/network/ble/ble_sec/#privacy-feature", - "text": "Bluetooth LE supports an optional feature during connection mode and connection procedures that reduces the ability to track a LE device over a period of time by changing the Bluetooth device address on a frequent basis. There are two variants of the privacy feature. In the first variant, private addresses are resolved and generated by the Host . In the second variant, private addresses are resolved and generated by the Controller without involving the Host after the Host provides the Controller device identity information. The Host may provide the Controller with a complete resolving list or a subset of the resolving list.\nDevice filtering becomes possible in the second variant when address resolution is performed in the Controller because the peer\u2019s device identity address can be resolved prior to checking whether it is in the white list. Note : When address resolution is performed exclusively in the Host, a device may experience increased pow er consumption because device filtering must be disabled. For more details on the privacy feature, refer to BLUETOOTH SPECIFICATION Version 4.2 [Vol 3, Part C] (Published 02 December 2014), Page 592.", + "text": "Bluetooth LE supports an optional feature during connection mode and connection procedures that reduces the ability to track a LE device over a period of time by changing the Bluetooth device address on a frequent basis. There are two variants of the privacy feature. In the first variant, private addresses are resolved and generated by the Host . In the second variant, private addresses are resolved and generated by the Controller without involving the Host after the Host provides the Controller device identity information. The Host may provide the Controller with a complete resolving list or a subset of the resolving list.\nDevice filtering becomes possible in the second variant when address resolution is performed in the Controller because the peer\u2019s device identity address can be resolved prior to checking whether it is in the white list. Note : When address resolution is performed exclusively in the Host, a device may experience increased pow er consumption because device filtering must be disabled. For more details on the privacy feature, refer to BLUETOOTH SPECIFICATION Version 4.2 [Vol 3, Part C] (Published 02 December 2014), Page 592.", "title": "Privacy Feature" }, { http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/b435bead/latest/network/ble/ble_sec/index.html ---------------------------------------------------------------------- diff --git a/latest/network/ble/ble_sec/index.html b/latest/network/ble/ble_sec/index.html index caee56b..9ff397d 100644 --- a/latest/network/ble/ble_sec/index.html +++ b/latest/network/ble/ble_sec/index.html @@ -425,8 +425,7 @@ <li>In the second variant, private addresses are resolved and generated by the <em>Controller</em> without involving the Host after the Host provides the Controller device identity information. The Host may provide the Controller with a complete resolving list or a subset of the resolving list. Device filtering becomes possible in the second variant when address resolution is performed in the Controller because the peerâs device identity address can be resolved prior to checking whether it is in the white list.</li> </ul> -<p><strong>Note</strong>: When address resolution is performed exclusively in the Host, a device may experience increased power consumption because device filtering must be disabled.</p> -<p>For more details on the privacy feature, refer to BLUETOOTH SPECIFICATION Version 4.2 [Vol 3, Part C] (Published 02 December 2014), Page 592.</p> +<p><strong>Note</strong>: When address resolution is performed exclusively in the Host, a device may experience increased power consumption because device filtering must be disabled. For more details on the privacy feature, refer to BLUETOOTH SPECIFICATION Version 4.2 [Vol 3, Part C] (Published 02 December 2014), Page 592.</p> <div class="row"> http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/b435bead/mkdocs/search_index.json ---------------------------------------------------------------------- diff --git a/mkdocs/search_index.json b/mkdocs/search_index.json index 3a5e6a5..187a837 100644 --- a/mkdocs/search_index.json +++ b/mkdocs/search_index.json @@ -6817,12 +6817,12 @@ }, { "location": "/network/ble/ble_sec/", - "text": "BLE Security\n\n\nThe Bluetooth Low Energy security model includes five distinct security concepts as listed below. For detailed specifications, see BLUETOOTH SPECIFICATION Version 4.2 [Vol 1, Part A].\n\n\n\n\n\n\nPairing\n: The process for creating one or more shared secret keys. In LE a single link key is generated by combining contributions from each device into a link key used during pairing. \n\n\n\n\n\n\nBonding\n: The act of storing the keys created during pairing for use in subsequent connections in order to form a trusted device pair. \nBonding is currently a roadmap item for Apache Mynewt.\n \n\n\n\n\n\n\nDevice authentication\n: Verification that the two devices have the same keys (verify device identity)\n\n\n\n\n\n\nEncryption\n: Keeps message confidential. Encryption in Bluetooth LE uses AES-CCM cryptography and is performed in the \nController\n.\n\n\n\n\n\n\nMessage integrity\n: Protects against message forgeries.\n\n\n\n\n\n\nBluetooth LE uses four association models depending on the I/O capabilities of the devices. \nApache Mynewt has first implemented support for \"Just Works\" only.\n\n\n\n\n\n\nJust Works\n: designed for scenarios where at least one of the devices does not have a display capable of displaying a six digit number nor does it have a keyboard capable of entering six decimal digits.\n\n\n\n\n\n\nNumeric Comparison\n: designed for scenarios where both devices are capable of displaying a six digit number and both are capable of having the user enter \"yes\" or \"no\". A good example of this model is the cell phone / PC scenario.\n\n\n\n\n\n\nOut of Band\n: designed for scenarios where an Out of Band mechanism is used to both discover the devices as well as to exchange or transfer cryptographic numbers used in the pairing process.\n\n\n\n\n\n\nPasskey Entry\n: designed for the scenario where one device has input capability but does not have the capability to display six digits and the other device has output capabilities. A good example of this model is the PC and keyboard scenario.\n\n\n\n\n\n\nKey Generation\n\n\nKey generation for all purposes in Bluetooth LE is performed by the \nHost\n on each LE device independent of any other LE device. \n\n\nPrivacy Feature\n\n\nBluetooth LE supports an optional feature during connection mode and connection procedures that reduces the ability to track a LE device over a period of time by changing the Bluetooth device address on a frequent basis. \nPrivacy support is currently a roadmap item for Apache Mynewt.\n\n\nThere are two variants of the privacy feature. \n\n\n\n\n\n\nIn the first variant, private addresses are resolved and generated by the \nHost\n.\n\n\n\n\n\n\nIn the second variant, private addresses are resolved and generated by the \nController\n without involving the Host after the Host provides the Controller device identity information. The Host may provide the Controller with a complete resolving list or a subset of the resolving list.\n\n\n\n\n\n\nDevice filtering becomes possible in the second variant when address resolution is performed in the Controller because the peer\u2019s device identity address can be resolved prior to checking whether it is in the white list.\n\n\nNote\n: When address resolution is performed exclusively in the Host, a device may experience increased power consumption because device filtering must be disabled.\n\n\nFor more details on the privacy feature, refer to BLUETOOTH SPECIFICATION Version 4.2 [Vol 3, Part C] (Published 02 December 2014), Page 592.", + "text": "BLE Security\n\n\nThe Bluetooth Low Energy security model includes five distinct security concepts as listed below. For detailed specifications, see BLUETOOTH SPECIFICATION Version 4.2 [Vol 1, Part A].\n\n\n\n\n\n\nPairing\n: The process for creating one or more shared secret keys. In LE a single link key is generated by combining contributions from each device into a link key used during pairing. \n\n\n\n\n\n\nBonding\n: The act of storing the keys created during pairing for use in subsequent connections in order to form a trusted device pair. \n\n\n\n\n\n\nDevice authentication\n: Verification that the two devices have the same keys (verify device identity)\n\n\n\n\n\n\nEncryption\n: Keeps message confidential. Encryption in Bluetooth LE uses AES-CCM cryptography and is performed in the \nController\n.\n\n\n\n\n\n\nMessage integrity\n: Protects against message forgeries.\n\n\n\n\n\n\nBluetooth LE uses four association models depending on the I/O capabilities o f the devices. \n\n\n\n\n\n\nJust Works\n: designed for scenarios where at least one of the devices does not have a display capable of displaying a six digit number nor does it have a keyboard capable of entering six decimal digits.\n\n\n\n\n\n\nNumeric Comparison\n: designed for scenarios where both devices are capable of displaying a six digit number and both are capable of having the user enter \"yes\" or \"no\". A good example of this model is the cell phone / PC scenario.\n\n\n\n\n\n\nOut of Band\n: designed for scenarios where an Out of Band mechanism is used to both discover the devices as well as to exchange or transfer cryptographic numbers used in the pairing process.\n\n\n\n\n\n\nPasskey Entry\n: designed for the scenario where one device has input capability but does not have the capability to display six digits and the other device has output capabilities. A good example of this model is the PC and keyboard scenario.\n\n\n\n\n\n\nKey Generation\n\n\nKey generation for a ll purposes in Bluetooth LE is performed by the \nHost\n on each LE device independent of any other LE device. \n\n\nPrivacy Feature\n\n\nBluetooth LE supports an optional feature during connection mode and connection procedures that reduces the ability to track a LE device over a period of time by changing the Bluetooth device address on a frequent basis. \n\n\nThere are two variants of the privacy feature. \n\n\n\n\n\n\nIn the first variant, private addresses are resolved and generated by the \nHost\n.\n\n\n\n\n\n\nIn the second variant, private addresses are resolved and generated by the \nController\n without involving the Host after the Host provides the Controller device identity information. The Host may provide the Controller with a complete resolving list or a subset of the resolving list.\n\n\n\n\n\n\nDevice filtering becomes possible in the second variant when address resolution is performed in the Controller because the peer\u2019s device identity address can be resolved prior to checking whether it is in the white list.\n\n\nNote\n: When address resolution is performed exclusively in the Host, a device may experience increased power consumption because device filtering must be disabled.\n\n\nFor more details on the privacy feature, refer to BLUETOOTH SPECIFICATION Version 4.2 [Vol 3, Part C] (Published 02 December 2014), Page 592.", "title": "NimBLE Security" }, { "location": "/network/ble/ble_sec/#ble-security", - "text": "The Bluetooth Low Energy security model includes five distinct security concepts as listed below. For detailed specifications, see BLUETOOTH SPECIFICATION Version 4.2 [Vol 1, Part A]. Pairing : The process for creating one or more shared secret keys. In LE a single link key is generated by combining contributions from each device into a link key used during pairing. Bonding : The act of storing the keys created during pairing for use in subsequent connections in order to form a trusted device pair. Bonding is currently a roadmap item for Apache Mynewt. Device authentication : Verification that the two devices have the same keys (verify device identity) Encryption : Keeps message confidential. Encryption in Bluetooth LE uses AES-CCM cryptography and is performed in the Controller . Message integrity : Protects against message forgeries. Bluetooth LE uses four association models depending on the I/O capabilities of the devices. Apache Mynew t has first implemented support for \"Just Works\" only. Just Works : designed for scenarios where at least one of the devices does not have a display capable of displaying a six digit number nor does it have a keyboard capable of entering six decimal digits. Numeric Comparison : designed for scenarios where both devices are capable of displaying a six digit number and both are capable of having the user enter \"yes\" or \"no\". A good example of this model is the cell phone / PC scenario. Out of Band : designed for scenarios where an Out of Band mechanism is used to both discover the devices as well as to exchange or transfer cryptographic numbers used in the pairing process. Passkey Entry : designed for the scenario where one device has input capability but does not have the capability to display six digits and the other device has output capabilities. A good example of this model is the PC and keyboard scenario.", + "text": "The Bluetooth Low Energy security model includes five distinct security concepts as listed below. For detailed specifications, see BLUETOOTH SPECIFICATION Version 4.2 [Vol 1, Part A]. Pairing : The process for creating one or more shared secret keys. In LE a single link key is generated by combining contributions from each device into a link key used during pairing. Bonding : The act of storing the keys created during pairing for use in subsequent connections in order to form a trusted device pair. Device authentication : Verification that the two devices have the same keys (verify device identity) Encryption : Keeps message confidential. Encryption in Bluetooth LE uses AES-CCM cryptography and is performed in the Controller . Message integrity : Protects against message forgeries. Bluetooth LE uses four association models depending on the I/O capabilities of the devices. Just Works : designed for scenarios where at least one of the devi ces does not have a display capable of displaying a six digit number nor does it have a keyboard capable of entering six decimal digits. Numeric Comparison : designed for scenarios where both devices are capable of displaying a six digit number and both are capable of having the user enter \"yes\" or \"no\". A good example of this model is the cell phone / PC scenario. Out of Band : designed for scenarios where an Out of Band mechanism is used to both discover the devices as well as to exchange or transfer cryptographic numbers used in the pairing process. Passkey Entry : designed for the scenario where one device has input capability but does not have the capability to display six digits and the other device has output capabilities. A good example of this model is the PC and keyboard scenario.", "title": "BLE Security" }, { @@ -6832,7 +6832,7 @@ }, { "location": "/network/ble/ble_sec/#privacy-feature", - "text": "Bluetooth LE supports an optional feature during connection mode and connection procedures that reduces the ability to track a LE device over a period of time by changing the Bluetooth device address on a frequent basis. Privacy support is currently a roadmap item for Apache Mynewt. There are two variants of the privacy feature. In the first variant, private addresses are resolved and generated by the Host . In the second variant, private addresses are resolved and generated by the Controller without involving the Host after the Host provides the Controller device identity information. The Host may provide the Controller with a complete resolving list or a subset of the resolving list. Device filtering becomes possible in the second variant when address resolution is performed in the Controller because the peer\u2019s device identity address can be resolved prior to checking whether it is in the white list. Note : When address resolution is perfo rmed exclusively in the Host, a device may experience increased power consumption because device filtering must be disabled. For more details on the privacy feature, refer to BLUETOOTH SPECIFICATION Version 4.2 [Vol 3, Part C] (Published 02 December 2014), Page 592.", + "text": "Bluetooth LE supports an optional feature during connection mode and connection procedures that reduces the ability to track a LE device over a period of time by changing the Bluetooth device address on a frequent basis. There are two variants of the privacy feature. In the first variant, private addresses are resolved and generated by the Host . In the second variant, private addresses are resolved and generated by the Controller without involving the Host after the Host provides the Controller device identity information. The Host may provide the Controller with a complete resolving list or a subset of the resolving list. Device filtering becomes possible in the second variant when address resolution is performed in the Controller because the peer\u2019s device identity address can be resolved prior to checking whether it is in the white list. Note : When address resolution is performed exclusively in the Host, a device may experience increased power consumption because device filtering must be disabled. For more details on the privacy feature, refer to BLUETOOTH SPECIFICATION Version 4.2 [Vol 3, Part C] (Published 02 December 2014), Page 592.", "title": "Privacy Feature" }, { http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/b435bead/network/ble/ble_sec/index.html ---------------------------------------------------------------------- diff --git a/network/ble/ble_sec/index.html b/network/ble/ble_sec/index.html index 2592ea0..a1e16e4 100644 --- a/network/ble/ble_sec/index.html +++ b/network/ble/ble_sec/index.html @@ -377,7 +377,7 @@ <p><strong>Pairing</strong>: The process for creating one or more shared secret keys. In LE a single link key is generated by combining contributions from each device into a link key used during pairing. </p> </li> <li> -<p><strong>Bonding</strong>: The act of storing the keys created during pairing for use in subsequent connections in order to form a trusted device pair. <font color="#F2853F"><em>Bonding is currently a roadmap item for Apache Mynewt.</em> </font></p> +<p><strong>Bonding</strong>: The act of storing the keys created during pairing for use in subsequent connections in order to form a trusted device pair. </p> </li> <li> <p><strong>Device authentication</strong>: Verification that the two devices have the same keys (verify device identity)</p> @@ -389,7 +389,7 @@ <p><strong>Message integrity</strong>: Protects against message forgeries.</p> </li> </ul> -<p>Bluetooth LE uses four association models depending on the I/O capabilities of the devices. <font color="#F2853F"><em>Apache Mynewt has first implemented support for "Just Works" only.</em></font></p> +<p>Bluetooth LE uses four association models depending on the I/O capabilities of the devices. </p> <ul> <li> <p><strong>Just Works</strong>: designed for scenarios where at least one of the devices does not have a display capable of displaying a six digit number nor does it have a keyboard capable of entering six decimal digits.</p> @@ -407,7 +407,7 @@ <h3 id="key-generation">Key Generation</h3> <p>Key generation for all purposes in Bluetooth LE is performed by the <em>Host</em> on each LE device independent of any other LE device. </p> <h3 id="privacy-feature">Privacy Feature</h3> -<p>Bluetooth LE supports an optional feature during connection mode and connection procedures that reduces the ability to track a LE device over a period of time by changing the Bluetooth device address on a frequent basis. <font color="#F2853F"><em>Privacy support is currently a roadmap item for Apache Mynewt.</em></font></p> +<p>Bluetooth LE supports an optional feature during connection mode and connection procedures that reduces the ability to track a LE device over a period of time by changing the Bluetooth device address on a frequent basis. </p> <p>There are two variants of the privacy feature. </p> <ul> <li>
