[Security] Private key transmitted to backend via unprotected API calls in wallet service

Summary

The DiaBackendWalletService transmits the user's raw Ethereum private key to the backend server via HTTP FormData in setIntegrityWallet$(), and receives private keys back in API responses through the DiaBackendWallet interface. This creates an unnecessarily large attack surface for private key compromise.

Affected Files

• src/app/shared/dia-backend/wallet/dia-backend-wallet.service.ts
  • Line ~66: setIntegrityWallet$() sends the private key as a form field to the backend
  • Line ~149: DiaBackendWallet interface includes private_key field in API responses
• src/app/shared/migration/service/migration.service.ts
  • Line ~179: Consumes private_key from backend wallet API response

Impact

• Severity: HIGH
• OWASP Category: A02:2021 - Cryptographic Failures
• If the backend server or any network intermediary (proxy, CDN, logging service) is compromised, all user private keys transmitted via this API are exposed
• API response bodies containing private keys may be logged by application performance monitoring tools, error tracking services, or server-side logging
• The private key is present in both request and response payloads, doubling the exposure surface
• This is distinct from #3357 (storage at rest) — this concerns the transmission of private keys over the network

Suggested Fix

1. Eliminate private key transmission: Instead of sending the raw private key to the backend, sign a challenge message locally and send the signature + public key for the backend to verify wallet ownership
2. Remove private_key from API responses: The backend should never return private keys. If the client needs to verify wallet association, use the public address instead
3. If backend storage is required for legacy reasons: Encrypt the private key client-side with a user-derived key before transmission, so the backend only ever sees ciphertext

References

• Related to #3357 (unencrypted private key storage)
• Related to #3362 (JWT token exposure in URLs)

Generated by Health Monitor with Omni

Start with setIntegrityWallet$() and the DiaBackendWallet interface in src/app/shared/dia-backend/wallet/dia-backend-wallet.service.ts, then trace the private_key consumer around line 179 in src/app/shared/migration/service/migration.service.ts. Review the API contract and related issues before choosing an approach. Done means raw private keys are no longer transmitted in requests or returned in responses while wallet association still works.