Add PasswordTransformer trait with platform implementations

[jkmassel]

Description

Add encrypted credential storage for persisting site authentication across app launches.

This PR introduces a PasswordTransformer trait and platform-specific implementations that encrypt credentials at rest, enabling AccountRepository (also introduced here) to persist sites and tokens securely.

This is the foundation for credential storage in:

• This project's example apps (Add WP.com OAuth login support #1190)
• The GutenbergKit sample apps
• Eventually the WordPress/Jetpack iOS and Android apps

Changes

1. PasswordTransformer trait + AES-256-GCM implementation (wp_mobile)

   • UniFFI-exported trait with encrypt/decrypt methods
   • Uses #[uniffi::export(with_foreign)] so platforms can provide hardware-backed implementations
   • Pure-Rust AesGcmPasswordTransformer serves as a cross-platform fallback (particularly for Linux where platform keystores are unavailable)
   • AccountRepository for storing and retrieving encrypted site credentials

2. Swift bindings for persistence types

   • Re-exports AccountRepository, PasswordTransformer, etc. to the public Swift API
   • Conditionally exposes AesGcmPasswordTransformer on Linux via #if os(Linux)
   • On Apple platforms, SecureEnclavePasswordTransformer fills this role instead

3. SecureEnclavePasswordTransformer (Apple)

   • ECIES encryption (P-256 ECDH + HKDF-SHA256 + AES-256-GCM) backed by the Secure Enclave
   • Falls back to software keys on simulators
   • Keys persisted via Keychain with the application name as kSecAttrService for visibility in Keychain Access
   • Tests run under @Suite(.serialized) to prevent cooperative thread pool deadlocks during SE key creation

4. KeystorePasswordTransformer (Android)

   • AES-256-GCM encryption backed by the Android Keystore
   • Prefers StrongBox (API 28+), falls back to TEE, works in software on emulators
   • Exposes isHardwareBacked property so callers can check the security level
   • Explicit base64 validation on decrypt for clear error messages

Test plan

• cargo test --lib — Rust unit tests for AesGcmPasswordTransformer and AccountRepository
• Swift unit tests for SecureEnclavePasswordTransformer (22 tests: round-trip, key persistence, error paths)
• Android instrumented tests for KeystorePasswordTransformer (15 tests: round-trip, key reuse, error paths, tampered ciphertext)
• SwiftLint and Detekt pass
• cargo clippy and cargo fmt pass

[crazytonyli]

Just for my understanding, we are going to use SecureEnclavePasswordTransformer on Apple platforms, AesGcmPasswordTransformer on Linux, and KeystorePasswordTransformer on Android, right? I'm not familiar with Android, so I won't comment on that.

The SecureEnclavePasswordTransformer seems to contain two implementations:

1. one backed by a SecureEnclave private key (not directly usable by third parties), and
2. the other with a traditional private key that's stored on disk

IMO, the second kind of private key is not secure, because it's stored on disk without any protection. According to the comment on SecureEnclavePasswordTransformer(keyFile:), it's intended to be used for the dev env. If that's the only use case, do we even need to go through the encryption and decryption process? I think we can just have a PlaintextPasswordTransformer, which has no encryption, for local development (like the example apps)?

Also, I'm not sure if the SecureEnclave encryption is necessary. I think we can delegate the encryption to the keychain? Here is a pseudo-code:

class KeychainPasswordTransformer {
  func encrypt(password: String) {
    let id = UUID()
    keychain.store(username: id, password: password, service: "wordpress-rs-accounts")
    return id
  }

  func decrypt(encrypted: String) -> String {
    keychain.get(username: encrypted, service: "wordpress-rs-accounts)
  }
}

---

I wonder if we can have a SecureKeyValueStore trait to replace the PasswordTransformer. The definition of PasswordTransformer requires the implementation to be able to encrypt and decrypt any plaintext. But I don't think we really need that level of abstraction.

Can we ask the platform to store the information for us securely, without thinking about encryption & decryption?

// pseudo-code: Just a simple key-value store.
trait SecureKeyValueStore {
  fn store(id: String /* AccountId */, data: Vec<u8>)
  fn get(id: String) -> Vec<u8>
}

The platform can decide how to store the data securely, so we likely don't need any encryption or decryption code.

[jkmassel]

Also, I'm not sure if the SecureEnclave encryption is necessary. I think we can delegate the encryption to the keychain? Here is a pseudo-code:

When running the app for macOS local development, you have to type your keychain password on every launch because the app's signature has changed. This is protection against Keychain enumeration attacks – if I were reviewing a patch someone contributed, you don't want it to read every keychain entry and upload what it finds to some remote server.

But that makes local development super annoying. One solution for this is using an Apple Development identity for dev builds, but then you need to propagate that to CI. That's a lot of complexity.

In this PR, the Apple platforms approach works the same as the Android one – the system vends a key out of its secure hardware, and we use that to encrypt the secrets in-place. Here's an outline of how it's stored for each case:

Platform	Key Type	Key Storage	Key in Storage
iOS / tvOS / watchOS / visionOS (device)	Secure Enclave P-256	Keychain	Opaque reference only
iOS / tvOS / watchOS / visionOS (simulator)	Software P-256	Keychain	Raw key, Keychain-protected
macOS (Apple Silicon / T2)	Secure Enclave P-256	Keychain	Opaque reference only
macOS (no Secure Enclave)	Software P-256	Keychain	Raw key, Keychain-protected
macOS (Apple Silicon / T2) + keyFile	Secure Enclave P-256	File (0o600)	Opaque reference only
macOS (no SE) + keyFile	Software P-256	File (0o600)	Raw key material
Linux	AES-256-GCM	Caller-provided shared secret	N/A

The only insecure storage mechanism here is macOS without a SEP – that's Intel machines without a T-series coprocessor.

I don't really want the protocol to act as a raw K/V store, because another big benefit to storing a single keychain entry for the whole app is that you don't run into sync issues between what's in the keychain and what's in the app's storage and you get guarantees about avoiding race conditions or write tearing.

[crazytonyli]

When running the app for macOS local development, you have to type your keychain password on every launch because the app's signature has changed.

Yeah, I get what you want to avoid here. But I think it's okay to bypass any security measures for local development and just write the password to a file?

I don't know much about cryptography. The large chunk of cryptography code looks quite intimidating to me, which is why I'd prefer to delegate that to the system. That's pretty much where all my suggestions are centered around 😅

I don't really want the protocol to act as a raw K/V store, because another big benefit to storing a single keychain entry for the whole app

You can generate a secret in Rust and store it in the K/V store, and use AesGcmPasswordTransformer internally. In doing that, you don't need the cryptography code in Swift and Kotlin.

Here is a potentially similar way to remove the cryptography code in Swift and Kotlin:

class Encryption: PasswordTransformer {
  let transformer: AesGcmPasswordTransformer
  init() {
    let secret: String = getOrCreateFromKeychain()
    transformer = AesGcmPasswordTransformer(secret: secret)
  }
  
  func encrypt() {
    transformer.encrypt()
  }

  func decrypt() {
    transformer.decrypt()
  }
}