• nixFREAK@sopuli.xyz
    link
    fedilink
    arrow-up
    6
    ·
    13 hours ago

    Ok, but there was no verification of the private key, so it’s not just “an import error” it’s also lazy to not verify what you generated.

  • joulethief@discuss.tchncs.de
    link
    fedilink
    arrow-up
    8
    ·
    14 hours ago

    I consider myself very tech-literate but as someone who has little theoretical knowledge on certificates and trust chains and everything, I can barely understand a thing reading this article. Can someome dumb this down for me just a little? Because I still want to know how all of this happened

    • PlasticMachinery@europe.pub
      link
      fedilink
      arrow-up
      14
      ·
      14 hours ago

      They generated a good key, but their (probably) slop coded python script truncated it to 4 The real key was something Like 47829827589393764883 or something and it got cut off

    • Fubarberry@sopuli.xyz
      link
      fedilink
      English
      arrow-up
      8
      ·
      14 hours ago

      When you generate a private key, it’s not supposed to be easily transported between devices. There’s a thing called a Hardware Security Module (HSM) which is meant to generate and securely store keys. eMudhra needed to generate keys for some certificates, but their new HSM chips were delayed, so they decided to generate the keys on someone else’s HSM. They then used a python script to try to export the keys, which would have required disabling security features of the HSM and packaging the keys into an encrypted “blob”. When they then extracted the keys from the blob later, it cut off most of the key, leaving only one byte of the key’s value (resulting in a key value between 1-255).

      They initially signed the certs with the full key, but in June 2025 they encountered a key mismatch, where their keys (the transferred keys with the short value) didn’t match. eMudhra said they used the wrong key the first time, and resigned the certs with the transferred insecure keys instead.