Skip to main content

· 3 min read
Marcin Szamotulski

High-level overview of sprint 42​

Eclipse Evasion​

We merged and released a new version of the ouroboros-network package (version 0.9.0.0) which includes big ledger peers feature. This is the primary peer selection mechanism to defend against eclipses. We also prepared a PR to updated ouroboros-cosnensus and ekg-forward packages.

CDDL specs for protocol codecs​

We made the cddl spec for network codec more inline with the implementation which is highly polymorphic. cddl doesn't have the notion of polymorphism, but has any which can generate any valid cbor term. We matched it with an Any type on the Haskell side and made all remaining tests & specs use it. This simplified the specifications and made it easier to understand which parts are defined in the spec, and which parts are left unspecified. See ouroboros-network#4595.

Ouroboros-Network-Framework API changes​

We also released ouroboros-network-framework and other network components. The ouroboros-network-framework package contains a redesign of API exposed to ouroboros-consensus. We consolidated, cleaned it and made it easier to extend in the future if there will be new arguments that need to be passed to mini-protocol initiator and responders which comes from the low-level network layer.

Nix setup (CI)​

We also made a major review of our nix setup. With help from our DevX team we ended up with a clean flake.nix file which can:

  • compile & test the code on x86_64-linux, x86_64-darwin and aarch64-darwin
  • cross-compile to Windows on x86_64-linux

And provides a shell which contains all the build tools, including ghc-9.6, hls, cddl, and more. See ouroboros-network#4640, ouroboros-network#4643.

Other contributions​

Cardano Network Service Assurance​

  • The work and writeup in finishing up the CNSA, first stage (first contract).
  • Getting Sam Cowger (Galois Inc) up to speed.
  • The IOG Networking team carried a reivew of CNSA project progress: a limitted code & design review.

Galois Review​

Sam Cowger and Mark Tullsen (Galois Inc) have made some progress on each of the tech debt issues

scoping, requirements, and getting started.

CI​

We added a nightly run for GitHub actions and made the GitHub actions test be executed with extra concurrency ouroboros-network#4637, ouroboros-network#4649.

We also added GitHub's dependabot ouroboros-network#4650.

Bootstrap Peers​

We settled on implementation design of bootstrap peers which is being implemented, ouroboros-network#4615.

· One min read
John Lotoski

High level summary​

The SRE team continues work on cardano environment improvements and general environment maintenance.

Some notable recent updates or improvements include:

  • Sanchonet and shelley-qa environments were updated to 8.2.1-pre.
  • Work on two new repos utilizing flake parts for cardano cluster generation, automation and operation.

Lower level summary​

Cardano-ops​

Cardano-parts​

Cardano-perf​

Cardano-playground​

Cardano-world​

Inputs-check​

  • A flake parts module to check input closure sizes recursively for optimization considerations: inputs-check

· One min read
Iñigo Querejeta Azurmendi

High level summary​

The open fronts that the crypto team is working on are:

  • Sidechains: Analysis of Halo2 SNARK verifier to plan a plutus implementation
  • mithril: Full node verifier
  • musig2: Include MuSig2 description in cryptography handbook
  • kes_agent: Finilising test and CI. Working on KES binary

Low level summary​

Mithril​

  • Full Node Verifier merged #939.

MuSig2​

  • Started describing MuSig2 to include it as part of the cryptography handbook

Sidechains​

  • Analysis of Halo2 verifier with the goal of implementing SNARK verifier in Plutus. Implemented ad-hoc IPA verifier. Work progress in this fork.

KES agent​

  • KES agent is ready:
    • CI ready #19
    • Receipt confirmation message #20
    • KES agent binary ready #21
    • Control client implemented #11

· One min read
Kostas Dermentzis

High level summary​

We have integrated many new Conway feutures and allow db-sync to sync sanchonet. We also continued testing and improving the new db-sync options.

Lower level summary​

  • Conway integration #1484
  • Support for Sanchonet #1476
  • Stake distribution is computed earlier #1484
  • Deposit ledger events are now used. This reduces the db queries and makes syncing faster #1484
  • Testing new db-sync options #1466
  • Added support for ghc-9.6 #1479
  • Tech debt: improve exceptions #1471

· 4 min read
Iñigo Querejeta Azurmendi

Security Issue Report: SECP256k1 bug​

Date Occurred: July 15, 2022 Severity: Potentially Very High if exploited on Mainnet Authors: Iñigo Querejeta Azurmendi

Date of Report: August 17, 2023

Summary of Issue​

Criticality Level​

Actually low (since the issue was detected prior to deployment) but potentially very high if it had been deployed to mainnet Context

New SECP256k1 Plutus bindings were being introduced in order to support interoperability with other major chains, such as Bitcoin and Ethereum. The intention was to deploy these as part of the Vasil hard-fork. The bindings were considered to be a low-security risk since the underlying library functions were well tested and had been deployed on other blockchains. How was the Issue Detected

The issue was detected via specific End-to-End tests that had been commissioned. It was (accidentally) triggered on the Cardano Testnet before a fix could be deployed there.

What Action was Taken​

The Cardano Testnet was permanently halted, and new test environments were deployed (Preview and Pre-Prod). Fixes were applied to prevent the use of the primitives. A full security audit was carried out on the bindings. The rollout of the primitives was postponed to a new hard fork (Valentine)

Potential Effect​

The potential effect was that an adversary might be able to craft invalid Plutus transactions to crash any node, requiring execution of the Cardano disaster recovery plan to revert to a safe state and bypass the transaction.

Actual Effect​

  • Delay to the Vasil hard-fork
  • Temporary removal of SECP256k1 primitives
  • Additional hard-fork to introduce SECP256k1 primitives

Ongoing Mitigations Needed, if any​

None

Responsibility for Mitigations​

Core team

Detailed description of Incident​

New Plutus secp256k1 cryptographic primitives for Plutus v2 failed to apply the necessary validity checks on the input data, meaning that the primitives could theoretically be used in an unsafe environment. The vulnerability was present in recent node versions (1.35.0 onwards), including ones deployed to Cardano Testnet.

The problem was not in the deserialization functions of the underlying library (Bitcoin's library) but rather that the Haskell functions that implemented the Plutus builtins were not calling them correctly. In particular, the library functions were designed to take structured data as input. However, the Haskell FFI implementation that was produced for the Plutus builtins allowed a caller to pass in (possibly) unstructured data. There were no checks that these data were structured in the correct way. This issue was detected during End-to-End testing.

  • This is the ECDSA signature verification algorithm that was used. It takes a SECP256k1_pubkey as input. That type is an opaque type with an expected structure: a parsed and valid public key. It was not immediately obvious that structured data needed to be passed to allow the function to be used safely.
  • The same happened with the Schnorr verification function. It takes as input a SECP256k1_xonly_pubkey, which is again an opaque structure that holds a parsed and valid public key.

The FFI skipped checks over these structured keys and directly passed the raw bytes that were given as arguments. If an adversary were to pass in data that was not properly structured, then it could result in unexpected behavior of the library. This could perhaps translate into an adversary being able to crash the nodes that ran these functions. All nodes in the network could be crashed by a single transaction that would then be executed repeatedly, so stalling the network until the disaster recovery process was initiated.

The fix was addressed in this PR. It consisted of using the external representation that the deserialization function expects and running the deserialization prior to signature verification. This was audited by security experts.

Recommendations​

  • Check all new Plutus bindings for correct use.
  • Audit all new Plutus built-in bindings.
  • Continue to develop specific End-to-End tests for all new Plutus features.
  • Do not assume that any existing library functions are "safe". Treat all external calls circumspectly.