<commit_before>/* mbed Microcontroller Library
 * Copyright (c) 2006-2015 ARM Limited
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *     http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

#ifndef _SECURITY_MANAGER_H_
#define _SECURITY_MANAGER_H_

#include <stdint.h>

#include "Gap.h"
#include "CallChainOfFunctionPointersWithContext.h"
#include "ble/BLETypes.h"

/**
 * Overview
 *
 * Security Manager is used to provide link security through encryption, signing, and authentication
 * which are made possible by pairing and optionally bonding. Pairing is the process of establishing
 * and/or exchanging keys used for the current connection. Bonding means saving this information so that
 * it can later be used after reconnecting without having to pair again. This saves time and power.
 *
 * There are many ways to provide these at different levels of security depending on your requirements
 * and the facilities provided by the application. The process starts with initialising the SecurityManager
 * with default options for new connections. Some settings can later be changed per link or globally.
 *
 * The important settings in the init() function are the MITM requirement and IO capabilities. Man in the
 * Middle (MITM) protection prevents an attack where one device can impersonate another device by
 * pairing with both devices at the same time. This protection is achieved sharing some information
 * between the devices through some independent channel. The IO capabilities of both devices dictate
 * what algorithm is used. For details @see BLUETOOTH SPECIFICATION Version 5.0 | Vol 3, Part H - 2.3.5.1.
 * You can change the IO capabilities after initialisation with setIoCapability(). This will take effect
 * for all subsequent pairings.
 *
 * Sharing this information through IO capabilities means user interaction which limits the degree of
 * protection due to the limit of the amount of data that we can expect the user to transfer. Another
 * solution is using OOB (out of band) communication to transfer this data instead which can send much
 * more data making MITM attack even less likely to succeed. OOB data has to be exchanged by the application
 * and provided to the Security Manager. Use setOOBDataUsage() to indicate you want to use it. The same call also
 * allows you to set whether or not the communication channel you are using to transmit the OOB data is
 * itself secure against MITM protection - this will set the level of the link security achieved using pairing
 * using this data.
 *
 * The most secure pairing is provided by Secure Connections which relies on public key cryptography.
 * Support for Secure Connections is dependent on both the stack and controller on both sides supporting
 * it. If either side doesn't support it Legacy Pairing will be used. This is an older standard of pairing.
 * If higher security is required legacy pairing can be disabled by calling allowLegacyPairing(false);
 *
 * How to use
 *
 * First thing you need to do is to initialise the manager by calling init() with your chosen settings.
 *
 * The SecurityManager communicates with your application through events. These will trigger calls in
 * the EventHandler you must provide by calling the setSecurityManagerEventHandler() function.
 *
 * The most important process is pairing. This may be triggered manually by calling requestPairing() or
 * may be called as a result of the application requiring encryption or encryption through
 * requestAuthentication() or setLinkEncryption().
 *
 * All these can be implicitly called by using setLinkSecurity() to conveniently set the required
 * security for the link. The SecurityManager will trigger all the process required to achieve the set
 * security level.
 *
 * Depending on the IO capabilities and OOB usage settings different pairing algorithms will be chosen.
 * They will produce appropriate events which must be handled by your EventHandler.
 *
 * The simplest example would be a pairing of a device with no IO capabilities and no OOB data available.
 * With such limited pairing capabilities the "just works" method will be employed. This does not provide
 * any MITM protection. The pairing (triggered implicitly or called explicitly) will result in an event
 * being generated on the peer calling pairingRequest(). The event handler must make a decision (either in
 * the application itself or based on user interaction) whether to accept the pairing and call
 * accetPairing() or cancelPairing(). The result will be communicated on both peers through an event calling
 * pairingResult() in the EventHandler.
 *
 *
 * Sequence diagram "Just Works" pairing
 *
 *  /----------- Device 1 --------------\  *------ BLE link ------*  /-------------- Device 2 -------------\
 *
 * App  EventHandler              SecurityManager              SecurityManager           EventHandler     App
 *  |       |                           |                            |                        |            |
 *  |---------------------------> requestPairing()                   |                        |            |
 *  |       |                           |------[pairing start]------>|                        |            |
 *  |       |                           |                            |----------------> pairingRequest() ->|
 *  |       |                           |                        acceptPairing() <------------------------- |
 *  |       |                           |<---[pairing complete]----->|                        |            |
 *  |<- pairingResult() <---------------|                            |----------------> pairingResult() -->|
 *  |       |                           |                            |                        |            |
 *
 *  @note the requestPairing() call isn't required to trigger pairing. Pairing will also be triggered
 *  if you request encryption and authentication and no bonding information is available. The sequence will
 *  be the same save for the lack of explicit requestPairing() call.
 *
 *
 *  Sequence diagram Encryption request when bonding information is available
 *
 *  /----------- Device 1 --------------\  *------ BLE link ------*  /-------------- Device 2 -------------\
 *
 * App  EventHandler              SecurityManager              SecurityManager           EventHandler     App
 *  |       |                           |                            |                        |            |
 *  |---------------------------> setLinkEncryption()                |                        |            |
 *  |       |                           |<-[encryption established]->|                        |            |
 *  |<- linkEncryptionResult() <--------|                            |---------> linkEncryptionResult() -->|
 *  |       |                           |                            |                        |            |
 *
 * @note if bonding information is not available, pairing will be triggered
 */

class SecurityManager {
public:
    /** events sent and received when passkey is being entered */
    enum Keypress_t {<commit_msg>added one more sequence diagram<commit_after>/* mbed Microcontroller Library
 * Copyright (c) 2006-2015 ARM Limited
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *     http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

#ifndef _SECURITY_MANAGER_H_
#define _SECURITY_MANAGER_H_

#include <stdint.h>

#include "Gap.h"
#include "CallChainOfFunctionPointersWithContext.h"
#include "ble/BLETypes.h"

/**
 * Overview
 *
 * Security Manager is used to provide link security through encryption, signing, and authentication
 * which are made possible by pairing and optionally bonding. Pairing is the process of establishing
 * and/or exchanging keys used for the current connection. Bonding means saving this information so that
 * it can later be used after reconnecting without having to pair again. This saves time and power.
 *
 * There are many ways to provide these at different levels of security depending on your requirements
 * and the facilities provided by the application. The process starts with initialising the SecurityManager
 * with default options for new connections. Some settings can later be changed per link or globally.
 *
 * The important settings in the init() function are the MITM requirement and IO capabilities. Man in the
 * Middle (MITM) protection prevents an attack where one device can impersonate another device by
 * pairing with both devices at the same time. This protection is achieved sharing some information
 * between the devices through some independent channel. The IO capabilities of both devices dictate
 * what algorithm is used. For details @see BLUETOOTH SPECIFICATION Version 5.0 | Vol 3, Part H - 2.3.5.1.
 * You can change the IO capabilities after initialisation with setIoCapability(). This will take effect
 * for all subsequent pairings.
 *
 * Sharing this information through IO capabilities means user interaction which limits the degree of
 * protection due to the limit of the amount of data that we can expect the user to transfer. Another
 * solution is using OOB (out of band) communication to transfer this data instead which can send much
 * more data making MITM attack even less likely to succeed. OOB data has to be exchanged by the application
 * and provided to the Security Manager. Use setOOBDataUsage() to indicate you want to use it. The same call also
 * allows you to set whether or not the communication channel you are using to transmit the OOB data is
 * itself secure against MITM protection - this will set the level of the link security achieved using pairing
 * using this data.
 *
 * The most secure pairing is provided by Secure Connections which relies on public key cryptography.
 * Support for Secure Connections is dependent on both the stack and controller on both sides supporting
 * it. If either side doesn't support it Legacy Pairing will be used. This is an older standard of pairing.
 * If higher security is required legacy pairing can be disabled by calling allowLegacyPairing(false);
 *
 * How to use
 *
 * First thing you need to do is to initialise the manager by calling init() with your chosen settings.
 *
 * The SecurityManager communicates with your application through events. These will trigger calls in
 * the EventHandler you must provide by calling the setSecurityManagerEventHandler() function.
 *
 * The most important process is pairing. This may be triggered manually by calling requestPairing() or
 * may be called as a result of the application requiring encryption or encryption through
 * requestAuthentication() or setLinkEncryption().
 *
 * All these can be implicitly called by using setLinkSecurity() to conveniently set the required
 * security for the link. The SecurityManager will trigger all the process required to achieve the set
 * security level.
 *
 * Depending on the IO capabilities and OOB usage settings different pairing algorithms will be chosen.
 * They will produce appropriate events which must be handled by your EventHandler.
 *
 * The simplest example would be a pairing of a device with no IO capabilities and no OOB data available.
 * With such limited pairing capabilities the "just works" method will be employed. This does not provide
 * any MITM protection. The pairing (triggered implicitly or called explicitly) will result in an event
 * being generated on the peer calling pairingRequest(). The event handler must make a decision (either in
 * the application itself or based on user interaction) whether to accept the pairing and call
 * accetPairing() or cancelPairing(). The result will be communicated on both peers through an event calling
 * pairingResult() in the EventHandler.
 *
 *
 * Sequence diagram "Just Works" pairing
 *
 *  /----------- Device 1 --------------\  *------ BLE link ------*  /-------------- Device 2 -------------\
 *
 * App  EventHandler              SecurityManager              SecurityManager           EventHandler     App
 *  |        |                          |                            |                        |            |
 *  |---------------------------> requestPairing()                   |                        |            |
 *  |        |                          |------[pairing start]------>|                        |            |
 *  |        |                          |                            |----------------> pairingRequest() ->|
 *  |        |                          |                        acceptPairing() <------------------------ |
 *  |        |                          |<---[pairing complete]----->|                        |            |
 *  |<- pairingResult() <---------------|                            |----------------> pairingResult() -->|
 *  |        |                          |                            |                        |            |
 *
 *  @note the requestPairing() call isn't required to trigger pairing. Pairing will also be triggered
 *  if you request encryption and authentication and no bonding information is available. The sequence will
 *  be the same save for the lack of explicit requestPairing() call.
 *
 *
 *  Sequence diagram Encryption request when bonding information is available
 *
 *  /----------- Device 1 --------------\  *------ BLE link ------*  /-------------- Device 2 -------------\
 *
 * App  EventHandler              SecurityManager              SecurityManager           EventHandler     App
 *  |       |                           |                            |                        |            |
 *  |---------------------------> setLinkEncryption()                |                        |            |
 *  |       |                           |<-[encryption established]->|                        |            |
 *  |<- linkEncryptionResult() <--------|                            |---------> linkEncryptionResult() -->|
 *  |       |                           |                            |                        |            |
 *
 * @note if bonding information is not available, pairing will be triggered
 *
 *
 * Sequence diagram for Secure Connections passkey entry pairing with one device having a display only
 * and other a keyboard
 *
 *  /----------- Device 1 (keyboard) ---\  *------ BLE link ------*  /-------------- Device 2 (display) ---\
 *
 * App  EventHandler              SecurityManager              SecurityManager           EventHandler     App
 *  |        |                          |                            |                        |            |
 *  |---------------------------> requestPairing()                   |                        |            |
 *  |        |                          |------[pairing start]------>|                        |            |
 *  |        |                          |                            |----------------> pairingRequest() ->|
 *  |        |                          |                        acceptPairing() <------------------------ |
 *  |        |                          |<---[secure con. pairing]-->|                        |            |
 *  |<- passkeyRequest() <--------------|                            |----------------> passkeyDisplay() ->|
 *  |        |                          |                            |                        |            |
 *
 *                       user reads the passkey on Device 2 and inputs it in Device 1
 *
 *  |        |                          |                            |                        |            |
 *  |-------------------------->passkeyEntered()                     |                        |            |
 *  |        |                          |<---[pairing complete]----->|                        |            |
 *  |<- pairingResult() <---------------|                            |----------------> pairingResult() -->|
 *  |        |                          |                            |                        |            |
 *
 */

class SecurityManager {
public:
    /** events sent and received when passkey is being entered */
    enum Keypress_t {
{'fraction_non_alphanumeric': 0.10312187665353637, 'fraction_numerical': 0.0029396202010700217, 'mean_word_length': 1.7042925278219396, 'pattern_counts': {'":': 0, '<': 26, '<?xml version=': 0, '>': 38, 'https://': 0, 'lorem ipsum': 0, 'www.': 2, 'xml': 0}, 'pii_count': 2, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 90, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '1678672', 'n_tokens_mistral': 3728, 'n_tokens_neox': 3515, 'n_words': 1749}