[Bug]: RSA_PKCS1_PADDING is no longer supported for private decryption

[martijnpoppen]

Client version

latest

Node version

18.19.1

Operating System type

Other

Operating system version

none

Describe the bug

Hi @bropat
I'm getting the RSA_PKCS1_PADDING is no longer supported for private decryption error on some of the Homey clients.
I saw your fix in the eufy-security-ws repo. Unfortunately I can only do stuff at runtime.

Do you know if it's possible to step away from the RSA_PKCS1_PADDING for livestreaming?
That would fix the issue for me, or do you know if i can set the REVERT_CVE_2023_46809 on runtime?

To reproduce

error:

[EufyLibrary] [p2p] [P2PClientProtocol.handleDataBinaryAndVideo] Error: AES key could not be decrypted! The entire stream is discarded. {
  error: {
    cause: undefined,
    message: 'Error: Error during decryption (probably incorrect key). Original error: TypeError: RSA_PKCS1_PADDING is no longer supported for private decryption, this can be reverted with --security-revert=CVE-2023-46809',
    context: undefined,
    stacktrace: 'Error: Error during decryption (probably incorrect key). Original error: TypeError: RSA_PKCS1_PADDING is no longer supported for private decryption, this can be reverted with --security-revert=CVE-2023-46809\n' +
      '    at module.exports.NodeRSA.$$decryptKey (/app/node_modules/node-rsa/src/NodeRSA.js:301:19)\n' +
      '    at module.exports.NodeRSA.decrypt (/app/node_modules/node-rsa/src/NodeRSA.js:249:21)\n' +
      '    at P2PClientProtocol.handleDataBinaryAndVideo (/app/node_modules/eufy-security-client/build/p2p/session.js:1355:63)\n' +
      '    at P2PClientProtocol.handleData (/app/node_modules/eufy-security-client/build/p2p/session.js:1295:18)\n' +
      '    at P2PClientProtocol.parseDataMessage (/app/node_modules/eufy-security-client/build/p2p/session.js:1152:26)\n' +
      '    at P2PClientProtocol.handleMsg (/app/node_modules/eufy-security-client/build/p2p/session.js:986:26)\n' +
      '    at Socket. (/app/node_modules/eufy-security-client/build/p2p/session.js:118:56)\n' +
      '    at Socket.emit (node:events:517:28)\n' +
      '    at Socket.emit (node:domain:489:12)\n' +
      '    at UDP.onMessage [as onmessage] (node:dgram:942:8)'
  },
  stationSN: 'T8030-REDACTED,
  key: 'REDACTED'
}

Screenshots & Logfiles

No response

Additional context

No response

[bropat]

@martijnpoppen

Do you know if it's possible to step away from the RSA_PKCS1_PADDING for livestreaming?

I only use this decryption method because Eufy uses it for encryption.
In short, no, it is not possible on my side.

Eufy would have to update the firmware of its devices and change the encryption method that the respective hardware also supports etc.. It will probably happen at some point with the new devices (or with the next negative headline about it ;)).

That would fix the issue for me, or do you know if i can set the REVERT_CVE_2023_46809 on runtime?

Not that I know of.

The only alternative option that I don't think makes sense in terms of performance/latency is to switch to a javascript native decryption library (with some library that supports RSA_PKCS1_PADDING).
I am of course open to any reasonable alternative suggestions.

[martijnpoppen]

Thanks @bropat
I'll investigate what can be done.

Just to verify, RSA_PKCS1_PADDING is only used for livestreaming or also for other parts in the library?

[bropat]

Just to verify, RSA_PKCS1_PADDING is only used for livestreaming or also for other parts in the library?

Basically it is used for:

1. livestreaming
2. download of videos (which no longer works as this part has been changed by Eufy)
3. p2p level 2 encryption (that's what I called it) of the commands sent. However, a fallback to level 1 (which is currently still supported by Eufy) is already implemented here if level 2 fails.

To summarise: you only really have an impact when live streaming.

[martijnpoppen]

@bropat Thanks!

I did find a workaround.

I came accros this : nodejs/node#52017

Setting this: key.setOptions({ environment: "browser" }); seems to work. i just tested it.

It would result in this:

export const getNewRSAPrivateKey = (): NodeRSA => {
    const key = new NodeRSA({ b: 1024 });
    key.setOptions({
        encryptionScheme: "pkcs1"
    });
    key.setOptions({ environment: "browser" });
    return key;
}

what are your thought about this?

Docs node-rsa: https://github.com/rzcoder/node-rsa/blob/master/README.md#options

[bropat]

We are talking about 8 times as slow for each packet it has to decrypt during a livestream, including higher CPU resources.
For this reason, I prefer the other solution.

decrypt-node: 2.144ms
decrypt-browser: 17.526ms

decrypt-node: 1.957ms
decrypt-browser: 16.181ms

decrypt-node: 1.924ms
decrypt-browser: 17.45ms

decrypt-node: 1.935ms
decrypt-browser: 16.046ms

decrypt-node: 1.847ms
decrypt-browser: 15.591ms

decrypt-node: 2.038ms
decrypt-browser: 16.295ms

decrypt-node: 2.034ms
decrypt-browser: 16.173ms

[martijnpoppen]

@bropat Thanks.
For my usecase this would work:

• Unable to set the Node arguments as it's running containerized
• Only streaming 3 seconds to create snapshots.

For now I enabled it in my own branch.
I'll check if I can find another solution.

[bropat]

In a future version I can also provide an option for this.

[martijnpoppen]

Yes would be nice! 👍🏼

[smitty078]

Everything actually works just fine as long as you have OpenSSL > 3.2 and your installation of NodeJS links against it.

From the NodeJS documentation (https://nodejs.org/api/crypto.html):
"The RSA_PKCS1_PADDING padding was disabled unless the OpenSSL build supports implicit rejection."

implicit rejection was implemented in OpenSSL 3.2 - macOS and many linux distros use older versions or libreSSL which do not support implicit rejection.

As there are so many different installations and variables involved, I leave it to the reader to determine the best path to upgrading their OpenSSL and insuring their NodeJS is using the appropriate version.