Skip to main content

DB-sync Team Update

· One min read
Kostas Dermentzis
Kostas Dermentzis
Cardano DB-Sync Software Engineer

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

SECP bindings Security Issue Report

· 4 min read
Iñigo Querejeta Azurmendi
Iñigo Querejeta Azurmendi
Cardano Lead Cryptography Engineer

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.

Node API & CLI Team Update

· 3 min read
Carlos LopezDeLara
Carlos LopezDeLara
Node Product Owner

2023-08-02 - 2023-08-15

High level summary​

  • cardano-node 8.2.1 (pre-release) to SanchoNet
  • Continue moving CLI into era-based top level command structure
  • Wire-up DREP key generation,
  • Fix DREP deregistration certificates
  • Implement Constitutional Committee Key generation on the CLI
  • Introducing era-based protocol parameters on the API
  • Removing depracated functions and types on the API

cardano-cli​

cardano-api​

cardano-node​

cardano-testnet​

docs​

Fix broken links in docs

CI & project maintenance​

Hydra Team Update

· One min read
Franco Testagrossa
Franco Testagrossa
Hydra Software Engineer
Sebastian Nagel
Sebastian Nagel
Hydra Team Lead

High-level summary​

This week, the Hydra team updated hydra-node to support cardano-node version 8.1.2, ensuring compatibility with the latest mainnet release. The team also participated in discussions about a "cardanonical" JSON schema and added it as a submodule to the project, contributing to improved data modeling and interoperability.

In terms of community engagement, the team successfully onboarded a new contributor, also participated in a RareEvo Twitter space, and continued preparations for the Hydra master-class.

What did the team achieve this week​

  • Updated dependencies to support cardano-node 8.1.2 #1007
  • Engaged in discussions about a “cardanonical” json schema and add it as submodule to the project #1013
  • Onboarded a new contributor to the hydra project (@locallycompact)
  • Joined RareEvo twitter space and continued preparation of hydra master-class

What are the goals of next week​

  • Update & streamline tutorial to work with latest version of hydra-node
  • Remove the internal commit functionality #954
  • Release 0.12.0

Performance & tracing update

· 2 min read
Michael Karg
Michael Karg
Performance and Tracing Team Lead

High level summary​

  • Benchmarking: We've concluded benchmarking node version 8.2.0.
  • Tracing: Optimization of the new tracing system has been merged; we're currently working on self-documenting tracing configuration.
  • Nomad backend: A PR that makes our backend take advantage of added flexibility of the new hardware cluster has been merged.

Low level overview​

Benchmarking​

As part of our release benchmarking cycle, we've completed and analysed the runs for the 8.2.0 version of cardano-node. In addition to the adjustment of sanity checks in our automation, we had to implement small changes in the analysis pipeline as well to accomodate the new version.

Tracing​

A significant amount of optimizations for the new tracing system has finally been merged to master. At the moment, we're working on having a trace message self-document the final tracing configuration of a running node. Apart from adding insight into the system, this feature also aims at making future hot reloading of tracing configuration explicit and straightforward.

Furthermore, we're setting up a final round of system integration level benchmarks comparing new against legacy tracing.

Nomad backend​

The new hardware cluster permits greater flexibility as far as SSH access is concerned. By using nomad for a consistent and reliable deployment, but taking advantage of direct connections for healthchecks and data transfer we believe we were able to reduce overall network latency in the nomad cluster. This improves confidence when capturing all network related measurements during our benchmarks.

A PR that adds these capabalities to our nomad backend - along with very many quality-of-life improvements - has been merged to master.