The blog post "Windows BitLocker – Screwed Without a Screwdriver" details a frustrating and potentially data-loss-inducing scenario involving Windows BitLocker encryption and a Secure Boot configuration change. The author recounts how they inadvertently triggered a BitLocker recovery key prompt after updating their computer's firmware. This seemingly innocuous update modified the Secure Boot configuration, specifically by enabling the Platform Key (PK) protection. BitLocker, designed with robust security in mind, interpreted this change as a potential security compromise, suspecting that an unauthorized actor might have tampered with the boot process. As a safeguard against potential malicious activity, BitLocker locked the drive and demanded the recovery key.
The author emphasizes the surprising nature of this event. There were no explicit warnings about the potential impact of a firmware update on BitLocker. The firmware update process itself didn't highlight the Secure Boot modification in a way that would alert the user to the potential consequences. This lack of clear communication created a situation where a routine update turned into a scramble for the BitLocker recovery key.
The post underscores the importance of securely storing the BitLocker recovery key. Without access to this key, the encrypted data on the drive becomes inaccessible, effectively resulting in data loss. The author highlights the potential severity of this situation, especially for users who may not have readily available access to their recovery key.
Furthermore, the post subtly criticizes the design of BitLocker and its interaction with Secure Boot. The author argues that triggering a recovery key prompt for a legitimate firmware update, especially one initiated by the user themselves, is an overreaction. A more nuanced approach, perhaps involving a warning or a less drastic security measure, would have been preferable. The author suggests that the current implementation creates unnecessary anxiety and potential data loss risks for users who perform routine system updates.
Finally, the post serves as a cautionary tale for other Windows users who utilize BitLocker. It stresses the necessity of understanding the implications of Secure Boot changes and the critical role of the BitLocker recovery key. It encourages proactive measures to ensure the recovery key is safely stored and accessible, mitigating the risk of data loss in similar scenarios. The author implies that better communication and more user-friendly design choices regarding BitLocker and Secure Boot interactions would significantly improve the user experience and reduce the risk of unintended data loss.
The blog post "Homomorphic Encryption in iOS 18" by Bastian Bohm details the introduction of homomorphic encryption capabilities within Apple's iOS 18 operating system, specifically focusing on the newly available APIs for performing calculations on encrypted data without requiring decryption. The author expresses excitement about this development, highlighting the potential for enhanced privacy and security in various applications.
The post begins by explaining the concept of homomorphic encryption, emphasizing its ability to process encrypted information directly, thus preserving the confidentiality of sensitive data. It distinguishes between Fully Homomorphic Encryption (FHE), which supports arbitrary computations, and Partially Homomorphic Encryption (PHE), which is limited to specific operations like addition or multiplication. The post clarifies that iOS 18 implements PHE, specifically focusing on additive homomorphic encryption.
The core of the post revolves around the newly introduced SecKeyEncryptedData class and its associated methods. The author provides a concise code example demonstrating how to create encrypted integers using this class and how to perform homomorphic addition on these encrypted values. The resulting sum remains encrypted, and only the holder of the decryption key can reveal its true value. The author meticulously breaks down the code snippet, explaining the role of each function and parameter. For instance, the post elucidates the process of generating a public key specifically designated for encrypted data operations and how this key is subsequently used to encrypt integer values. It also explains the significance of the perform method in executing homomorphic operations on these encrypted integers.
Furthermore, the post discusses the underlying cryptographic scheme employed by Apple, revealing that it leverages a variant of the Paillier cryptosystem. This choice is deemed suitable for integer additions and is acknowledged for its established security properties. The post also touches upon the practical limitations of PHE, specifically noting the inability to perform other operations like multiplication or comparison directly on the encrypted data without decryption.
Finally, the author speculates on the potential applications of this technology within the Apple ecosystem. The example given is privacy-preserving data collection, suggesting how homomorphic encryption could enable the aggregation of user statistics without compromising individual data privacy. This could be useful for applications like collecting usage metrics or accumulating health data while ensuring that the individual contributions remain confidential. The author concludes with an optimistic outlook on the future implications of homomorphic encryption within the iOS environment and expresses anticipation for further advancements in this field.
The Hacker News post titled "Homomorphic encryption in iOS 18" spawned a modest discussion with a handful of comments focusing on the practicalities and limitations of the technology, rather than the announcement itself. No one expressed outright excitement or skepticism about the announcement, instead offering pragmatic observations.
One commenter pointed out that the homomorphic encryption being utilized is limited to integer addition and multiplication, and thus isn't fully homomorphic encryption (FHE) in the broader, more powerful sense. They clarified that true FHE allows arbitrary computation on encrypted data, which is not what Apple is implementing. This comment served as an important clarification to distinguish the specific type of homomorphic encryption being employed.
Another user expanded on this by mentioning that the specific technique used is called "additive homomorphic encryption" and likely leverages the Paillier cryptosystem. This added technical depth to the discussion, providing a potential underlying mechanism for Apple's implementation. They then speculated about its use case, suggesting it could be applied to scenarios like federated learning or aggregated metrics collection.
A subsequent comment explored the performance limitations of homomorphic encryption. The commenter noted the significant computational overhead associated with these techniques, which makes them unsuitable for many real-time or performance-sensitive applications. This comment highlighted the trade-offs involved in using homomorphic encryption, emphasizing that while it offers enhanced privacy, it comes at the cost of performance.
Finally, one commenter linked to a related project called "Concrete," further adding context to the types of operations and optimizations possible within the homomorphic encryption space. This provides an avenue for those interested in learning more about practical implementations and advancements in the field.
Overall, the comments section offers a concise and informed discussion focusing on the technical nuances of Apple's implementation rather than broad speculation or hype. They provide valuable context and clarification regarding the specific type of homomorphic encryption being used and its inherent limitations.
Summary of Comments ( 57 )
https://news.ycombinator.com/item?id=42747877
HN commenters generally concur with the article's premise that relying solely on BitLocker without additional security measures like a TPM or Secure Boot can be risky. Several point out how easy it is to modify boot order or boot from external media to bypass BitLocker, effectively rendering it useless against a physically present attacker. Some commenters discuss alternative full-disk encryption solutions like Veracrypt, emphasizing its open-source nature and stronger security features. The discussion also touches upon the importance of pre-boot authentication, the limitations of relying solely on software-based security, and the practical considerations for different threat models. A few commenters share personal anecdotes of BitLocker failures or vulnerabilities they've encountered, further reinforcing the author's points. Overall, the prevailing sentiment suggests a healthy skepticism towards BitLocker's security when used without supporting hardware protections.
The Hacker News post "Windows BitLocker – Screwed Without a Screwdriver" generated a moderate amount of discussion, with several commenters sharing their perspectives and experiences related to BitLocker and disk encryption.
Several commenters discuss alternative full-disk encryption solutions they consider more robust or user-friendly than BitLocker. Veracrypt is mentioned multiple times as a preferred open-source alternative. One commenter specifically highlights its support for multiple bootloaders and ease of recovery. Others bring up LUKS on Linux as another open-source full-disk encryption option they favor.
The reliance on closed-source solutions for critical security measures like disk encryption is a concern raised by some. They emphasize the importance of transparency and the ability to inspect the code, particularly when dealing with potential vulnerabilities or backdoors. In contrast, one user expressed confidence in Microsoft's security practices, suggesting that the closed-source nature doesn't necessarily imply lower security.
A few commenters shared personal anecdotes of BitLocker issues, including problems recovering data after hardware failures. These stories highlighted the real-world implications of relying on a system that can become inaccessible due to unforeseen circumstances.
There's a discussion about the potential dangers of relying solely on TPM for key protection. The susceptibility of TPMs to vulnerabilities or physical attacks is raised as a concern. One user suggests storing the recovery key offline, independent of the TPM, to mitigate this risk. Another points out the importance of physically securing the machine itself, as a stolen laptop with BitLocker enabled but dependent on TPM could be potentially vulnerable to attack.
Some users questioned the specific scenario described in the original blog post, with one suggesting that the inability to boot may have been due to a Secure Boot issue unrelated to BitLocker. They also highlighted the importance of carefully documenting the recovery key to prevent data loss.
Finally, one commenter mentions encountering similar issues with FileVault on macOS, illustrating that the challenges and complexities of disk encryption are not unique to Windows. They note that while these solutions are designed to protect data, they can sometimes hinder access, especially in non-standard scenarios like hardware failures or OS upgrades.