🖌️4. WebKey OS Technical Architecture and Standards
Last updated
Last updated
The WTEE protocol is designed to protect the security of the WebKey system and is based on secure protocols at the system's core used to safeguard the security of sensitive data and code. It constructs a secure area on hardware devices to ensure that code and data running within it are protected from external attacks. WTEE provides a hardware-isolated secure world to protect the security of sensitive data and ensure the correct execution of programs.
TEE provides a runtime environment completely isolated from systems like Android/Linux:
Even if Android is rooted, attackers cannot read or tamper with TEE;
TEE operates independently from Android, running its own operating system and application ecosystem.
TEE does not require additional hardware support:
Utilizing technologies like ARM TrustZone, Intel SGX, RISC-V PMP, most mainstream chips already support it;
Switching controlled by software, the isolation between TEE and Android is ensured by the chip, providing higher security, lower costs, better performance, and lower power consumption.
TEE Four Elements
TEE implements the following common functions:
verifiable launch and remote attestation
runtime isolation/memory curtaining
trusted l/O
secure storage/sealing
Use Case: For the full lifecycle protection of digital identity certificate binding/expiry/update/revoke processes.
Security Solution:
Blockchain wallet Master Key and mnemonic security are at the core of wallet security. The Master Key may be tampered with or stolen during storage and usage. When backing up a wallet or importing keys, the mnemonic displayed on the screen or entered by the user may be stolen.
TEE Blockchain Cold Wallet Solution:
Ensure the Master Key does not leave the TEE
Use TUI for protection throughout business logic involving mnemonics.
Application Security:
1. Pre-installation and relevant audits of applications
Run CTS tests before pre-installing applications online, and pass virus, vulnerability, and automated tests.
2. Application installation and permissions, application signing
Grant permissions to pre-installed or whitelisted applications, and avoid using commonly known public keys for device signing.
3. Isolation of applications and processes
Root processes are the most common targets for privilege escalation attacks, so reducing the number of root processes helps reduce the escalation risk.
Ensure the minimum necessary code running as root on the device. Use regular Android processes as much as possible instead of root processes. Isolate root code from untrusted data and access it through inter-process communication (IPC) as much as possible. Root processes do not listen through network sockets. Root processes do not include general runtimes (e.g., Java Virtual Machine).
Hardware Security:
When selecting memory for devices, choose memory that includes mitigation measures against Rowhammer-style attacks.
On devices, secure storage and processing of available encryption keys can usually be achieved through hardware-supported Keymaster implemented in an isolated environment (such as a Trusted Execution Environment (TEE)).
Provide operations in the following categories:
Generate keys
Import and export asymmetric keys (without key wrapping)
Import raw symmetric keys (without key wrapping)
Perform asymmetric encryption and decryption using appropriate padding modes
Perform asymmetric signing and verification using digests and appropriate padding modes
Perform symmetric encryption and decryption in appropriate modes (including AEAD modes)
Generate and verify symmetric message authentication codes
Biometric Authentication a. Carefully acquire, store, and process biometric data for user authentication;
b. Specify the primary authentication method before using any other form of
authentication (including biometrics);
c. Require explicit confirmation when using passive biometric modes (such as facial recognition) for transactions involving identity-bound keys (e.g., payments);
d. Ensure all biometric data and processing use completely secure channels. Store this data in secure isolated environments, such as a Trusted Execution Environment (TEE) or a secure element.
Dynamic Loading of SELinux Policies Do not dynamically load SELinux policies on Android devices. Avoid issues such as:
a. Preventing the acceptance of critical security patches.
b. Allowing root operations on devices through policy reloading.
c. Providing vectors for man-in-the-middle attacks against policy update programs.
d. Device failures due to errors in policy updates.
Backdoors and Development Tools To provide higher security and avoid backdoor attacks, effectively manage permissions at the system level, disable Root permissions, and developer mode when devices are shipped. ADB is disabled by default on hardware devices.
Key Management Do not share signing keys with external parties;
If a signing key is compromised, generate a new key and perform dual signing for all applications in the future;
Store all keys in highly secure hardware modules or services that require multi-factor authentication for access.
