Stories with Tag Digital Signatures

• How (not) to sign a JSON object (2019)

  permalink

  Posted: 2025-02-09 14:38:52

  Verbose tl;dr

  Latacora's blog post "How (not) to sign a JSON object" cautions against signing JSON by stringifying it before applying a signature. This approach is vulnerable to attacks that modify whitespace or key ordering, which changes the string representation without altering the JSON's semantic meaning. The correct method involves canonicalizing the JSON object first – transforming it into a standardized, consistent byte representation – before signing. This ensures the signature validates only identical JSON objects, regardless of superficial formatting differences. The post uses examples to demonstrate the vulnerabilities of naive stringification and advocates using established JSON Canonicalization Schemes (JCS) for robust and secure signing.

  This blog post from Latacora, titled "How (not) to sign a JSON object (2019)," discusses the intricacies and common pitfalls of digitally signing JSON objects, specifically focusing on ensuring the integrity and authenticity of the data. The author emphasizes that simply signing a JSON string representation is insufficient due to the flexibility of JSON syntax. Variations in whitespace, key ordering, and numeric representation can all result in different string representations of the same underlying JSON object, leading to signature verification failures even though the semantic meaning of the data remains unchanged.

  The post meticulously dissects several flawed approaches, illustrating the vulnerabilities they introduce. One such approach is naively signing the stringified JSON. This is problematic because different JSON libraries might produce slightly different string outputs for the same JSON object, causing signature verification to fail. Another inadequate method involves canonicalizing the JSON before signing, but relying on insufficiently rigorous canonicalization methods. For example, simply sorting keys alphabetically doesn't account for variations in numeric representation or whitespace.

  The author then proposes a more robust solution: using a deterministic JSON serialization method. This method ensures that a given JSON object will always be serialized into the exact same string, regardless of the platform or library used. By signing this deterministic representation, the signature will reliably verify as long as the underlying data remains unchanged. The post highlights the importance of using a well-defined and widely adopted canonicalization algorithm to avoid interoperability issues.

  Furthermore, the blog post delves into the security implications of using non-deterministic JSON serialization. It explains how an attacker could potentially manipulate the JSON structure, altering insignificant details like whitespace or key order, to create a different string representation that still carries the same semantic meaning but invalidates the signature. This could allow for undetected tampering with the data.

  The post concludes by recommending specific libraries and tools for implementing secure JSON signing, emphasizing the critical need for careful consideration of these seemingly minor details to guarantee the integrity and authenticity of signed JSON objects. The overall message is that signing JSON requires a meticulous and deliberate approach, relying on established standards and deterministic serialization to prevent vulnerabilities and ensure the reliability of digital signatures.

  • JSON
  • Security
  • Signing
  • Digital Signatures
  • Cryptography
  • JWT
  • JWS
  • Web Security
  • best practices
  • data integrity
  • serialization
  • Encoding
  • 2019

  Summary of Comments ( 0 )
  https://news.ycombinator.com/item?id=42990948

  Verbose tl;dr

  HN commenters largely agree with the author's points about the complexities and pitfalls of signing JSON objects. Several highlighted the importance of canonicalization before signing, with some mentioning specific libraries like JWS and json-canonicalize to ensure consistent formatting. The discussion also touches upon alternatives like JWT (JSON Web Tokens) and COSE (CBOR Object Signing and Encryption) as potentially better solutions, particularly JWT for its ease of use in web contexts. Some commenters delve into the nuances of JSON's flexibility, which can make secure signing difficult, such as varying key order and whitespace handling. A few also caution against rolling your own cryptographic solutions and advocate for using established libraries where possible.

  The Hacker News post "How (not) to sign a JSON object (2019)" has generated several comments discussing various aspects of JSON signing and security practices.

  Several commenters focus on the importance of canonicalization before signing. One commenter emphasizes that the article's core message boils down to "canonicalize before signing," highlighting how failing to do so can introduce vulnerabilities. They further illustrate the point by referencing Python's json.dumps function and how different keyword arguments can lead to different string representations of the same JSON object, ultimately resulting in different signatures. Another commenter points out that using JSON for signing is inherently tricky due to the numerous variations possible in a serialized JSON object. They recommend CBOR (Concise Binary Object Representation) as a more suitable alternative for signing because of its consistent binary representation. This reinforces the idea that using a standardized, unambiguous data format is crucial for secure signing.

  The discussion also delves into specific vulnerabilities related to different JSON parsing libraries. One commenter mentions that some libraries accept duplicate keys, which can be exploited by attackers. They suggest that "canonicalization is about enforcing a schema and rejecting invalid input," emphasizing that strict validation is essential for preventing such attacks. Another user highlights specific problems with PHP’s json_decode function and how it handles duplicate keys, which could further expose systems to security risks if not carefully addressed.

  Another thread in the comments explores the concept of "deterministic JSON," where commenters discuss the challenges in achieving consistent serialization. One commenter notes the difficulty of creating a truly deterministic JSON representation across different languages due to variations in floating-point representations, character encoding, and key ordering.

  Several users shared examples of libraries and tools designed for secure JSON signing, including json-canonicalize and various JWS (JSON Web Signature) libraries. These comments offer practical solutions for developers seeking to implement secure signing practices.

  Finally, there's some discussion around JSON Web Signatures (JWS) and JWT (JSON Web Tokens). One commenter criticizes the use of JWT, arguing that JWS provides more flexibility and is sufficient for most use cases. They imply that JWT adds unnecessary complexity and might encourage less secure practices. Another user reinforces this by suggesting the use of detached signatures, emphasizing that signing only the relevant data minimizes the attack surface.

  In summary, the comments on the Hacker News post highlight the critical importance of canonicalization before signing JSON, discuss the challenges and vulnerabilities associated with inconsistent JSON representations, recommend alternative formats like CBOR, and provide practical advice on using tools and libraries designed for secure JSON signing. The discussion also touches upon the nuances of JWS and JWT, suggesting simpler approaches for enhanced security.

• A brief history of code signing at Mozilla

  permalink

  Posted: 2025-02-07 17:51:49

  Verbose tl;dr

  Mozilla's code signing journey began with a simple, centralized system using a single key and evolved into a complex, multi-layered approach. Initially, all Mozilla software was signed with one key, posing significant security risks. This led to the adoption of per-product keys, offering better isolation. Further advancements included build signing, allowing for verification even before installer creation, and update signing to secure updates delivered through the application. The process also matured through the use of hardware security modules (HSMs) for safer key storage and automated signing infrastructure for increased efficiency. These iterative improvements aimed to enhance security by limiting the impact of compromised keys and streamlining the signing process.

  This blog post by "hearsum" meticulously chronicles the evolution of code signing practices at Mozilla, providing a detailed account of the challenges, adaptations, and technical decisions made over the years to enhance the security and integrity of their software distributions. The narrative begins with the early days of Mozilla's code signing efforts, highlighting the initial reliance on a single code signing certificate and the manual processes involved. This period is characterized by its simplicity, but also by its vulnerability to potential security breaches and operational inefficiencies. The author underscores the inherent risk of a single point of failure represented by the sole certificate.

  As Mozilla's software offerings expanded and diversified, so too did the complexity of their code signing infrastructure. The blog post describes the transition to a more sophisticated system involving multiple code signing certificates, carefully differentiated by product and platform. This approach aimed to mitigate the risk associated with a single compromised certificate, isolating potential damage to a specific product line rather than the entire software ecosystem. The author elaborates on the logistical challenges of managing multiple certificates across various teams and geographical locations.

  A key turning point in Mozilla's code signing journey is the introduction of hardware security modules (HSMs). These specialized devices provide a secure and tamper-resistant environment for storing and managing cryptographic keys, significantly enhancing the security posture of the code signing process. The blog post details the complexities involved in integrating HSMs into the existing workflow, emphasizing the need for robust access control mechanisms and secure key handling procedures. The author specifically mentions the exploration of different HSM solutions and the eventual selection of a cloud-based HSM service, underscoring the advantages of scalability, availability, and disaster recovery capabilities offered by this approach.

  The narrative then delves into the challenges of automating the code signing process, a critical requirement for ensuring efficiency and repeatability. The author describes the initial reliance on manual scripting and the subsequent migration to a more robust and scalable automation framework. This evolution enabled Mozilla to streamline the code signing workflow, reducing the risk of human error and accelerating the release cycle. Furthermore, the blog post highlights the importance of integrating code signing into the Continuous Integration/Continuous Delivery (CI/CD) pipeline, enabling seamless and automated code signing during the build process.

  Finally, the author discusses the ongoing efforts to enhance the security and resilience of Mozilla's code signing infrastructure. This includes exploring advanced techniques such as dual code signing, which involves signing code with both an internal certificate and an external certificate from a trusted Certificate Authority (CA), adding an extra layer of verification and protection against potential CA compromises. The post concludes by emphasizing the continuous commitment to improving the security and integrity of Mozilla's software releases through ongoing refinement and adaptation of their code signing practices. This commitment reflects the organization's dedication to protecting its users from malicious software and ensuring the trustworthiness of its products.

  • Code Signing
  • Mozilla
  • History
  • Software Security
  • Digital Signatures
  • certificates
  • Browser Security
  • Web Security
  • PKI
  • Software Development

  Summary of Comments ( 80 )
  https://news.ycombinator.com/item?id=42975436

  Verbose tl;dr

  HN commenters generally praised the article for its clarity and detail in explaining a complex technical process. Several appreciated the focus on the practical, real-world challenges and compromises involved, rather than just the theoretical ideal. Some shared their own experiences with code signing, highlighting additional difficulties like the expense and bureaucratic hurdles, particularly for smaller developers. Others pointed out the inherent limitations and potential vulnerabilities of code signing, emphasizing that it's not a silver bullet security solution. A few comments also discussed alternative or supplementary approaches to software security, such as reproducible builds and better sandboxing.

  The Hacker News post "A brief history of code signing at Mozilla" generated a moderate discussion with several insightful comments. Many commenters focused on the complexities and frustrations of code signing, particularly in the context of Mozilla's cross-platform support and evolving security landscape.

  One commenter highlighted the often overlooked fact that code signing isn't a silver bullet guarantee of security, but rather a measure of provenance. They emphasized that signed code can still be malicious, and users should exercise caution even with signed applications. This commenter also touched on the economics of code signing, mentioning the costs associated with certificates and the challenges smaller developers face.

  Another commenter shared their personal experience with code signing, recounting the hassle and expense involved, particularly for distributing software across different platforms like Windows and macOS. They expressed frustration with the opaque nature of the process and the lack of clear documentation, echoing a sentiment shared by several others. This commenter also questioned the efficacy of code signing given the potential for vulnerabilities in the signing process itself.

  Several commenters discussed the technical details of code signing, including the different types of certificates, the use of timestamping, and the challenges of managing certificates within a large organization like Mozilla. They explored the trade-offs between security and usability, and the difficulties of balancing user experience with the need to protect against malware.

  One commenter specifically mentioned the increasing complexity of code signing on macOS, noting Apple's increasingly stringent requirements and the challenges this poses for developers. They pointed out the potential for disruptions and the difficulty of keeping up with Apple's evolving policies.

  Finally, several comments touched upon the broader implications of code signing for the open-source community. Some expressed concern that the costs and complexity of code signing could create barriers to entry for smaller projects and discourage open-source development. Others suggested alternative approaches, such as reproducible builds, as a potential solution to some of the challenges posed by code signing.

  Overall, the comments on the Hacker News post paint a picture of code signing as a necessary but complex and often frustrating aspect of software development, particularly for large organizations like Mozilla that support multiple platforms. The discussion highlights the ongoing challenges of balancing security, usability, and cost, and the need for clearer documentation and more streamlined processes.

• Sigstore: Making sure your software is what it claims to be

  permalink

  Posted: 2025-01-21 20:34:14

  Verbose tl;dr

  Sigstore aims to solve the problem of software supply chain security by making it easy to sign software artifacts and verify those signatures. It provides free tooling and a public good transparency log, enabling developers to sign releases with short-lived certificates tied to their identities (e.g., GitHub and email). This allows users to easily verify the provenance and integrity of software, ensuring that it hasn't been tampered with and genuinely originates from the claimed source. Sigstore simplifies the complex process of code signing, removing the need for managing long-lived keys and complicated infrastructure. This makes it significantly more practical for developers to secure their software supply chains and builds trust with end users.

  Sigstore is a free and open-source service designed to dramatically improve the security of the software supply chain. It addresses the critical problem of ensuring that software you download and run is genuinely what it claims to be, originating from the expected source and not tampered with along the way. This is achieved through a novel combination of transparency, automation, and cryptographic verification using digital signatures, similar to how HTTPS secures web browsing, but applied specifically to software artifacts.

  Traditionally, verifying the provenance and integrity of software has been complex, often relying on manual processes and cumbersome key management practices. Sigstore streamlines this process by automating the generation and management of short-lived cryptographic keys, eliminating the need for developers to maintain their own long-term signing keys, which can be a significant security vulnerability if compromised. These ephemeral keys are tied to identities through OpenID Connect (OIDC), a widely adopted authentication standard used by many major identity providers. This allows developers to leverage their existing organizational identities to sign their software, simplifying the authentication process and making it more secure.

  The signed attestations, along with the software artifacts themselves, are then stored in a tamper-proof public transparency log called Rekor. This log provides a permanent and auditable record of all signed software releases, allowing anyone to independently verify the integrity and authenticity of a particular software artifact. This significantly enhances transparency within the software supply chain, making it easier to detect malicious attempts to introduce compromised software. Because the log is publicly searchable, users can verify a signature even if they don't trust the publisher directly.

  Fulcio, Sigstore's free certificate authority, issues short-lived certificates linking the signing identity and the ephemeral key. This eliminates the need for developers to manage and secure their own code signing certificates, further streamlining the signing process and minimizing the attack surface. The integration with OIDC allows developers to use their existing identity provider, making the process seamless and easily integrated into existing workflows.

  By combining keyless signing, transparency logs, and a free certificate authority, Sigstore provides a powerful and comprehensive solution for securing the software supply chain. It empowers developers to sign and verify software easily and securely, while providing end-users with the assurance that the software they are using is trustworthy and has not been tampered with. This contributes significantly to improving the overall security posture of the software ecosystem by making it more difficult for attackers to distribute malicious code disguised as legitimate software. The open-source nature of the project fosters community involvement and allows for independent audits and scrutiny, further strengthening trust in the system.

  • Software Supply Chain Security
  • Sigstore
  • Software Signing
  • Digital Signatures
  • Open Source Security
  • software verification
  • Supply Chain Attacks
  • Code Signing
  • Security
  • DevOps
  • SLSA
  • Software Integrity
  • Provenance

  Summary of Comments ( 5 )
  https://news.ycombinator.com/item?id=42784892

  Verbose tl;dr

  Hacker News commenters generally expressed strong support for Sigstore and its mission of improving software supply chain security. Several praised its ease of use and integration with existing tools, noting the significantly lowered barrier to entry for signing releases compared to traditional methods. Some highlighted the importance of key transparency and the clever use of OpenID Connect for identity verification. A few commenters discussed the potential impact on various ecosystems like Debian and Python, expressing hope for wider adoption and speculating on the future development of the project. Concerns were raised about the reliance on centralized services and potential single points of failure, but these were often met with counter-arguments about the federated nature of OpenID and the transparency of the log. Some users questioned the long-term viability of free certificate issuance, and others debated the nuances of different signing models and their relative security implications.

  The Hacker News post titled "Sigstore: Making sure your software is what it claims to be" (linking to sigstore.dev) generated a moderate amount of discussion with a mix of praise for the project, inquiries about its practical application, and comparisons to other security initiatives.

  Several commenters expressed enthusiasm for Sigstore, emphasizing its potential to significantly improve software supply chain security. One user highlighted the ease of use and integration with existing tools as major advantages, particularly for open-source projects where maintaining complex security infrastructure can be challenging. Another lauded the transparency and auditability provided by the public log, making it easier to track the provenance of software artifacts. The simplicity of key management using OpenID Connect was also mentioned favorably, eliminating the need for developers to manage their own private keys.

  Some commenters focused on practical considerations and sought clarification on specific aspects of Sigstore. One user questioned how Sigstore handles dependencies, asking whether it verifies the signatures of all dependencies recursively. Another raised concerns about the revocation process, wondering how compromised keys would be handled and what impact that would have on the integrity of signed artifacts. There was also a discussion about the reliance on certificate transparency logs, with some users expressing concerns about the potential for log manipulation or censorship.

  Comparisons were drawn to other security initiatives like The Update Framework (TUF) and in-toto. One commenter pointed out that while TUF addresses similar security concerns, Sigstore simplifies key management and signature verification, potentially making it more accessible to a wider range of developers. Another user noted the similarities between Sigstore and in-toto, particularly in their use of transparency logs, but highlighted Sigstore's focus on code signing as a differentiating factor.

  A few commenters expressed skepticism about the project's long-term viability, questioning whether it would gain widespread adoption and whether it truly addressed the complex challenges of software supply chain security. One user raised concerns about the potential for "security theater," suggesting that Sigstore might provide a false sense of security without addressing the root causes of vulnerabilities.

  Overall, the comments reflect a general interest in Sigstore and its potential to improve software security, but also reveal some valid concerns and questions about its practical implementation and long-term effectiveness. The discussion highlights the complexity of the software supply chain security problem and the need for multifaceted solutions.