March 28, 2024

Thoughts on California’s Proposed Connected Device Privacy Bill (SB-327)

This post was authored by Noah Apthorpe.

On September 6, 2018, the California Legislature presented draft legislation to Governor Brown regarding security and authentication of Internet-connected devices. This legislation would extend California’s existing reasonable data security requirement—which already applies to online services—to Internet-connected devices.  

The intention of this legislation to prevent default passwords and other egregious authentication flaws is admirable, especially given the extent of documented security vulnerabilities in Internet of things (IoT) devices. Many such vulnerabilities, including default passwords and cleartext data transmissions (e.g., in IoT toys and medical devices discovered by researchers at Princeton), stem from lazy developer practices resulting in devices with minimal (or nonexistent) security or privacy protections. Such flaws could be addressed with well-known best practices that would not place excessive burden on device manufacturers.  With this context in mind, we applaud California’s effort to mandate minimal security and privacy protections for connected devices.

Unfortunately, as critics have pointed out, the wording of the proposed legislation is imprecise, especially regarding “reasonable security features.” Rather than reiterate this criticism, we point out some additional technical limitations of the proposed legislation, focusing on cases where the current language does not properly address security flaws as intended. We hope that these examples will help inform future improvements to this or other IoT security and privacy legislation.

1798.91.04.b.1: “The preprogrammed password is unique to each device manufactured.”
Mandating unique passwords for each device still leaves room for passwords that are still easily guessable. For example, a manufacturer could assign consecutive integers as passwords to all devices and be in compliance, but such passwords could be easily enumerated by an attacker. Related problems have already occurred. In 2015, TP-LINK routers were shipped with unique WiFi passwords derived from the hardware (MAC) addresses of each device. This made it trivial to observe traffic from one of these routers and subsequently guess the WiFi password. Much research has gone into the topic of generating secure passwords, the takeaways of which should be incorporated into any default password prevention law. Ultimately, additional criteria on preprogrammed unique passwords are needed for this bill to provide the intended security benefits.

1798.91.04.b.2: “The device contains a security feature that requires a user to generate a new means of authentication before access is granted to the device for the first time.”
This alternative requirement leaves open the possibility that devices or device features that users never access will not receive unique, secure passwords or other new authentication means. For example, many users never access the administrative interface of their home router (which typically has a different authentication method than the WiFi network itself). If the first login attempt is from an attacker, the attacker could receive the new authentication credentials.

Additionally, this requirement does not address the potential for devices to employ otherwise insecure authentication systems that still generate new credentials upon first access. As an analogy, just because an Internet user creates a new password for each online account does not mean that each of these passwords is necessarily secure. Again, additional criteria on the authentication system are needed.

1798.91.05.b: “‘Connected device’ means any device, or other physical object that is capable of connecting to the Internet, directly or indirectly, and that is assigned an Internet Protocol address or Bluetooth address.”
This extends the purview of the proposed legislation to PCs, laptops, smartphones, servers, and any other computing device that can access the Internet, even though the law is being promoted specifically as a protection for IoT devices.  While we are in favor of additional security and privacy protections on all networked devices, this broad scope may prevent improvements in the specificity of future versions of the legislation which may only be applicable to IoT, mobile, or other subcategory of devices.

1798.91.06.a: “This title shall not be construed to impose any duty upon the manufacturer of a connected device related to unaffiliated third-party software or applications that a user chooses to add to a connected device.”
This leaves unaddressed the complex ecosystem of third-party software that is incorporated into IoT and other Internet-connected devices before they reach the user. As an example, how does this law apply to Android smartphones for which the hardware is made by one manufacturer, the operating system is made by another (Google), and still other companies create mobile applications that come pre-loaded on the phone? The manufacturer of the hardware unlikely implements any authentication visible to the user. Instead, the operating system provides authentication for user access to the phone (usually via a PIN or a biometric fingerprint), while individual apps may have their own authentication measures. Future versions of the bill should clearly specify which criteria apply to the wide range of operating systems, applications, and software libraries from third-parties that provide core security, privacy, and authentication features for many devices.

Final Thoughts
Legal requirements that connected devices avoid well-known and easily fixed security flaws, such as default passwords, are long overdue. Yet, such legislation must recognize the complexity of cybersecurity issues. The above examples demonstrate the type of technical “gotchas” that can hide in well-meaning regulatory language. As California SB-327 or related legislation proceeds, we hope that legislators will consult with academic or industry researchers who have spent considerable effort developing, testing, and refining security and privacy solutions in a wide variety of technology contexts.