Troubleshooting BL602 PSK Calculation Problems
Introduction
Are you grappling with PSK (Pre-Shared Key) or PBKDF2_SHA1 calculation snags on your BL602? You're certainly not alone! This article dives deep into addressing and resolving these issues, particularly within the context of the Cozylife Hygrometer BC148-WT and the OpenBK7231T_App. We'll explore potential causes, debugging steps, and practical solutions to ensure your device connects seamlessly and operates reliably. Whether you're a seasoned developer or a tech enthusiast, this guide aims to provide valuable insights and workarounds for your BL602-related challenges. We will start by examining the initial problem reported by a user who encountered crashes during the PSK calculation process, then delve into the debugging steps, the workaround they discovered, and finally, offer a broader perspective on how to tackle similar issues.
Initial Problem: Crashing During PSK Calculation
A user reported experiencing crashes with their 1M BL602 devices in Cozylife Hygrometer BC148-WT units. To fit the firmware, they had disabled several drivers, as shown in the provided diff. The core issue manifested as crashes around the hmac_sha1_vector function, a critical component in the PSK calculation process. The logs indicated that the system would halt during this function's execution, making it impossible for the device to establish a stable Wi-Fi connection. This type of crash is particularly problematic because it occurs deep within the security layer, suggesting potential issues with memory management, algorithm implementation, or configuration parameters. The user's detailed logs provide a valuable starting point for understanding the sequence of events leading to the crash, highlighting the specific function calls and stack usage just before the failure.
Debugging Steps and Analysis
When encountering issues like these, a systematic debugging approach is crucial. The user spent two days debugging, which underscores the complexity of the problem. Effective debugging involves several key steps. The first step involves analyzing logs meticulously to pinpoint the exact location of the crash and identify any patterns or anomalies. In this case, the logs clearly indicated that the crashes occurred within the hmac_sha1_vector function. The second step involved reviewing code changes to identify any recent modifications that might have introduced the bug. By examining the diff provided, the user could assess whether disabling certain drivers had inadvertently affected the PSK calculation process. Memory analysis is another critical step, especially when dealing with crashes related to cryptographic functions. These functions often involve manipulating sensitive data in memory, and memory corruption or buffer overflows can lead to crashes. Hardware-specific considerations are also important, particularly when working with embedded devices like the BL602. Understanding the device's memory map, interrupt handling, and peripheral configurations can provide valuable clues. Finally, isolating the problem by testing different configurations and scenarios helps narrow down the root cause. In this case, the user's workaround, which bypasses the PBKDF2_SHA1 calculation, suggests that the issue might be specific to that function or its interaction with other components.
The Dirty Workaround: Bypassing PBKDF2_SHA1 Calculation
Faced with persistent crashes, the user devised a clever workaround by modifying the OpenBL602 SDK. The key insight was that the crashes occurred during the PBKDF2_SHA1 calculation, which is used to derive the PSK from the Wi-Fi password and SSID. Instead of performing this calculation on the device, the workaround allows users to provide a pre-generated PSK in hexadecimal format directly. This bypasses the problematic PBKDF2_SHA1 function, preventing the crashes. The code modification involves checking if the provided password is a 64-character hexadecimal string. If so, it assumes that the password is the precomputed PSK and uses it directly. This approach has a significant advantage: it allows the device to connect to Wi-Fi without crashing. However, it's essential to recognize that this is a workaround, not a definitive fix. Bypassing the PBKDF2_SHA1 calculation means that the device is no longer deriving the PSK from the password and SSID, which could have security implications if the pre-generated PSK is compromised. The user also provided a Python script (generate_psk_hex.py) to help others generate the precomputed PSK from their Wi-Fi password and SSID. This script is a valuable tool for those using the workaround, as it simplifies the process of generating the required hexadecimal PSK string.
Code Snippets and Explanation
Let's break down the code snippets provided by the user to understand the changes made and their implications.
Disabling Drivers
The initial diff shows that the user disabled several drivers to reduce the firmware size. This is a common practice when working with embedded devices with limited memory. However, it's crucial to understand the dependencies between different components. Disabling a driver might inadvertently affect other parts of the system. In this case, the user disabled drivers such as ENABLE_CALENDAR_EVENTS, ENABLE_DRIVER_BL0942, ENABLE_DRIVER_CSE7766, ENABLE_DRIVER_WEMO, ENABLE_DRIVER_DHT, ENABLE_DRIVER_DDP, ENABLE_DRIVER_SSDP, ENABLE_DRIVER_SM16703P, and ENABLE_DRIVER_PIXELANIM. While these changes might have helped reduce the firmware size, they could also have introduced subtle issues that interact with the PSK calculation process. It's essential to test thoroughly after disabling drivers to ensure that all critical functionalities remain intact.
diff --git a/src/obk_config.h b/src/obk_config.h
index 3e559ed1..64e956cf 100644
--- a/src/obk_config.h
+++ b/src/obk_config.h
@@ -195,26 +195,27 @@
#define ENABLE_LITTLEFS 1
#define ENABLE_NTP 1
// #define ENABLE_NTP_DST 1
-#define ENABLE_CALENDAR_EVENTS 1
+#define ENABLE_CALENDAR_EVENTS 0
#define ENABLE_DRIVER_LED 1
#define ENABLE_DRIVER_BL0937 1
-#define ENABLE_DRIVER_BL0942 1
-#define ENABLE_DRIVER_CSE7766 1
-#define ENABLE_DRIVER_WEMO 1
+#define ENABLE_DRIVER_BL0942 0
+#define ENABLE_DRIVER_BL0942SPI 0
+#define ENABLE_DRIVER_CSE7766 0
+#define ENABLE_DRIVER_WEMO 0
#define ENABLE_DRIVER_FREEZE 0
-#define ENABLE_DRIVER_DHT 1
+#define ENABLE_DRIVER_DHT 0
// parse things like $CH1 or $hour etc
#define ENABLE_EXPAND_CONSTANT 1
#define ENABLE_TASMOTA_JSON 1
-#define ENABLE_DRIVER_DDP 1
-#define ENABLE_DRIVER_SSDP 1
+#define ENABLE_DRIVER_DDP 0
+#define ENABLE_DRIVER_SSDP 0
#define ENABLE_DRIVER_CHT83XX 1
-#define ENABLE_DRIVER_DS1820 1
+#define ENABLE_DRIVER_DS1820 0
#define ENABLE_OBK_SCRIPTING 1
-// #define ENABLE_I2C 1
+#define ENABLE_I2C 1
#define ENABLE_ADVANCED_CHANNELTYPES_DISCOVERY 1
-#define ENABLE_DRIVER_SM16703P 1
-#define ENABLE_DRIVER_PIXELANIM 1
+#define ENABLE_DRIVER_SM16703P 0
+#define ENABLE_DRIVER_PIXELANIM 0
#if (OBK_VARIANT == OBK_VARIANT_BERRY)
#define ENABLE_OBK_BERRY 1
@@ -226,7 +227,7 @@
//#undef ENABLE_DRIVER_CSE7766
//#undef ENABLE_DRIVER_BL0937
//#undef ENABLE_DRIVER_BL0942
-#define ENABLE_DRIVER_IRREMOTEESP 1
+#define ENABLE_DRIVER_IRREMOTEESP 0
//#endif
#elif PLATFORM_BEKEN
Bypassing PBKDF2_SHA1
The core of the workaround lies in this code modification. It adds a check to see if the provided password is a 64-character hexadecimal string. If it is, the code bypasses the PBKDF2_SHA1 calculation and uses the password directly as the PSK. This is a practical solution for the immediate problem, but it's crucial to understand the security implications.
diff --git a/components/network/wifi_manager/bl60x_wifi_driver/wifi_mgmr_ext.c b/components/network/wifi_manager/bl60x_wifi_driver/wifi_mgmr_ext.c
index 7f3019375..350395be4 100644
--- a/components/network/wifi_manager/bl60x_wifi_driver/wifi_mgmr_ext.c
+++ b/components/network/wifi_manager/bl60x_wifi_driver/wifi_mgmr_ext.c
@@ -206,6 +206,13 @@ int wifi_mgmr_psk_cal(char *password, char *ssid, int ssid_len, char *output)
int ret;
char psk[32];
+ if (strlen(password) == 64) {
+ // Bypass: assume password is precomputed hex PSK
+ bl_os_printf("PSK bypass activated\r\n");
+ strcpy(output, password);
+ return 0;
+ }
+
ret = pbkdf2_sha1(password, ssid, ssid_len, 4096, (uint8_t *)psk, sizeof(psk));
if (0 == ret) {
utils_bin2hex(output, psk, 32);
@@ -343,7 +350,7 @@ int wifi_mgmr_sta_connect_ext(wifi_interface_t *wifi_interface, char *ssid, char
int ssid_len = ssid ? strlen(ssid) : 0;
int passphr_len = passphr ? strlen(passphr) : 0;
- if (!ssid || ssid_len > 32 || (passphr && ((passphr_len < 8 && passphr_len != 5) || passphr_len > 63))) {
+ if (!ssid || ssid_len > 32 || (passphr && ((passphr_len < 8 && passphr_len != 5) || passphr_len > 64))) {
return -1;
}
Increased Password Length
This change increases the maximum password length from 63 to 64 characters. This is likely related to the workaround, as the precomputed PSK is a 64-character hexadecimal string. This adjustment ensures that the precomputed PSK can be accommodated without truncation.
Security Implications and Considerations
While the workaround effectively resolves the crashing issue, it introduces potential security concerns that must be carefully considered. Precomputed PSKs, if compromised, can expose the network to unauthorized access. Unlike dynamically generated PSKs, a compromised precomputed key remains vulnerable indefinitely unless it is actively changed. This necessitates robust key management practices, including secure storage and periodic rotation of PSKs. The bypassed PBKDF2_SHA1 function serves a crucial role in enhancing security by deriving the PSK from the password and SSID using a computationally intensive process. This process makes it significantly harder for attackers to crack the password, even if they intercept the PSK. Bypassing this function weakens the security of the Wi-Fi connection, making it more susceptible to brute-force attacks and other security threats. It is paramount to implement secure storage mechanisms for precomputed PSKs. These keys should be stored in encrypted form and protected from unauthorized access. Hardware Security Modules (HSMs) or secure elements can provide a higher level of protection for sensitive cryptographic keys. Furthermore, regularly rotating PSKs is essential to minimize the risk of long-term compromise. This involves generating new PSKs periodically and updating the device and network configurations accordingly. Automating this process can help ensure that key rotation is performed consistently and without manual intervention. Finally, monitoring for security vulnerabilities is an ongoing process. Developers and users should stay informed about potential security threats and vulnerabilities in the BL602 and related software. Applying security patches and updates promptly can help mitigate these risks and maintain a secure environment. In summary, while the workaround provides a practical solution to the crashing issue, it should be viewed as a temporary measure. A comprehensive security strategy must be implemented to address the potential risks associated with precomputed PSKs and the bypassed PBKDF2_SHA1 function.
Alternative Solutions and Best Practices
While the provided workaround addresses the immediate crashing issue, it's essential to explore alternative solutions and best practices for a more robust and secure fix. Identifying the root cause of the PBKDF2_SHA1 calculation crash is paramount. This may involve in-depth debugging, memory analysis, and potentially using specialized tools to trace the execution flow and memory usage of the function. Common causes of crashes in cryptographic functions include memory corruption, buffer overflows, and incorrect parameter handling. Once the root cause is identified, a proper fix can be implemented, ensuring the security and stability of the system. Optimizing PBKDF2_SHA1 implementation can also mitigate performance issues and potential vulnerabilities. This may involve using hardware acceleration if available, carefully managing memory allocation, and ensuring that the implementation adheres to cryptographic best practices. Checking SDK and library versions is crucial to ensure that you are using the latest versions with the most recent bug fixes and security patches. Outdated libraries may contain known vulnerabilities or performance issues that have been addressed in newer releases. Reporting the issue to the OpenBL602 SDK maintainers is essential to contribute to the overall stability and security of the platform. Providing detailed information about the issue, including logs, code snippets, and steps to reproduce the problem, helps the maintainers diagnose and fix the bug efficiently. Collaborating with the community can also lead to valuable insights and alternative solutions. Online forums, mailing lists, and issue trackers are excellent platforms for sharing experiences, asking questions, and discussing potential fixes. In addition to these steps, adhering to secure coding practices is crucial to prevent similar issues in the future. This includes validating inputs, avoiding buffer overflows, handling errors gracefully, and following cryptographic best practices. Regular security audits can also help identify potential vulnerabilities and ensure that the system remains secure over time. By adopting these alternative solutions and best practices, developers can build more robust and secure systems based on the BL602 and OpenBL602 SDK.
Conclusion
In conclusion, troubleshooting PSK/PBKDF2_SHA1 calculation issues on the BL602 requires a methodical approach, combining debugging, workarounds, and a deep understanding of security implications. The user's experience highlights the importance of community collaboration and the balance between immediate fixes and long-term security. While the provided workaround offers a temporary solution, a comprehensive approach involving root cause analysis, security audits, and adherence to best practices is essential for robust and secure BL602-based applications. Remember to always prioritize security while implementing workarounds and strive for long-term solutions that address the root cause of the problem.
For more information on secure coding practices, consider exploring resources from OWASP (Open Web Application Security Project). This will provide you with a deeper understanding of web application security and best practices.
