FREQUENTLY ASKED QUESTIONS PAGE

3. Which devices will be supported in the future?

Devices are carefully selected based on their merits later the project will engage in hardware and firmware level improvements rather than simply making suggestions and reporting bugs upstream in those areas. Much of the ongoing work on the project involves changes that are specific to different devices, and the majority of this ongoing work is aimed at officially supported devices.

Devices must meet the project’s standards in order to be considered as potential targets. Standard hardware-based security features such as hardware-backed keystores, verified boot, attestation, and various hardware-based exploit mitigations must be available in addition to support for installing other operating systems. Devices must also have adequate IOMMU integration for isolating components such as the GPU, radios (NFC, Wi-Fi, Bluetooth, Cellular), media decode / encode, image processor, and so on, because if the hardware / firmware support is missing or broken, there is little the OS can do to provide an alternative.

In order to provide proper full security updates, devices must have proper ongoing support for their firmware and hardware-specific software such as drivers. End-of-life devices that are no longer receiving these updates will not be supported.

In order to support a device, the necessary resources must be available and dedicated to it. Releases for each supported device must be robust and stable, with all standard functionality functioning properly and each release tested.

Hardware, firmware, and device-specific software, such as drivers, all play a significant role in a device’s overall security. The goal of the project is not to slightly improve some aspects of insecure devices, and supporting a wide range of devices would be directly contradictory to the project’s values. A lot of the low-level work is also closely related to the hardware.

4. Why is it that older devices are no longer supported?

OryonOS aims to provide devices that are reasonably private and secure. It will be unable to do so once device support code such as firmware, kernel, and vendor code is no longer actively maintained. Even if the community were willing to take over maintenance of the open source code and replace the rest, firmware would be a major issue, and the community has never been active or interested in device support enough to consider trying this.

OryonOS, unlike many other platforms, has a much higher quality standards than simply having devices that are fully functional, as they must also provide the expected level of security. It would become more realistic to provide significantly longer device support once OryonOS controls the hardware and firmware through custom hardware designed for it. Until then, device longevity will be determined by manufacturer support. It’s also worth noting that phone vendors who claim to provide longer support frequently don’t, and some never even ship firmware updates when the hardware is still supported by the different suppliers.

OryonOS also has strict standards for the privacy and security properties of the hardware and firmware, which are constantly being improved. Although the rate of improvement has slowed, each hardware generation still brings significant improvements. Over time, the older hardware becomes a significant liability and slows down the project. When exceptions for old devices must be listed, it becomes difficult to simply make statements about the project’s security. The project eventually wants to drop devices for this reason, but has always kept them running until the end-of-life date to give people more time to migrate.

5. How does disk encryption work?

OryonOS makes use of an improved version of the Android Open Source Project’s modern filesystem-based disk encryption implementation. The officially supported devices have significant hardware-based support to improve the security of the encryption implementation. OryonOS fully supports hardware-based encryption features, as well as other hardware-based security features.

Firmware and operating system partitions are exact duplicates of the images published in official releases. Every boot validates the authenticity and integrity of these partitions via a root of trust. No data is read from these images unless it has been cryptographically verified. Because the images are publicly available, encryption is out of the question. Verified boot provides far superior security to disk encryption. More information on verified boot will be provided in a later section.

The data partition contains all of the operating system’s persistent state. Filesystem-based encryption with metadata encryption is used to implement full disk encryption. All data, file names, and other metadata are always encrypted before being stored. This is commonly referred to as file-based encryption, but filesystem-based encryption makes more sense. Rather than running a block-based encryption layer, it is implemented by the Linux kernel as part of the ext4 / f2fs implementation. The ability to use fine-grained keys rather than a single global key that is always in memory once the device is booted is a benefit of filesystem-based encryption.

Disk encryption keys are generated at random using a high-quality CSPRNG and encrypted with a key encryption key. Key encryption keys are generated at runtime and are never saved.

User profiles contain sensitive information. Each user profile has its own unique, randomly generated disk encryption key, as well as its own unique key encryption key, which is used to encrypt it. The owner profile is unique in that it is used to store sensitive operating system data for the entire system. This is why, after a reboot, the owner profile must be logged in before other user profiles can be used. The data in other profiles is not accessible to the owner profile. Filesystem-based encryption is designed so that files can be deleted without the keys to their data and file names, allowing the owner profile to delete other profiles while they are still active.

OryonOS supports the termination of secondary user profile sessions after logging into them. It adds an end session button to the lockscreen and the global action menu, which can be accessed by holding down the power button. This completely removes the encryption keys and returns the profiles to their original state. Because it encrypts sensitive system-wide operating system data, this cannot be done for the owner profile without rebooting.

Using a secondary profile for regular use allows you to use the device without decrypting the data in your primary profile. It also allows you to put it to sleep without having to restart the device. Even if you use the same pass for multiple profiles, each of them will have a unique key encryption key, and a compromise of the OS while one of them is active will not leak the pass. The benefit of using separate passwords is that an attacker cannot record you entering them.

AES-256-XTS is used to encrypt file data, and AES-256-CTS is used to encrypt file names. From the per-profile encryption keys, or the global encryption key for non-sensitive data stored outside of profiles, a unique key is derived using HKDF-SHA512 for each regular file, directory, and symbolic link. To encrypt the file names, the directory key is used. The file name padding in OryonOS is increased from 16 bytes to 32 bytes. In addition to finer-grained file name encryption, AES-256-XTS with the global encryption key is used to encrypt filesystem metadata as a whole.

Using scrypt, the OS generates a password token from the profile’s lock method credential. This is the primary input for key derivation.

As the Weaver token on the secure element (Titan M on Pixels), the OS stores a high entropy random value and uses it as another input for key derivation. The Weaver token is saved alongside a Weaver key generated by the operating system from the password token. The secure element must have the correct Weaver key in order to retrieve the Weaver token. Each attempt at key derivation is accompanied by a secure internal timer that implements hardware-based delays. It quickly escalates to one-day waits before the next attempt. Because the secure element can reliably wipe a Weaver slot, Weaver also provides reliable data wiping.

When a profile is deleted, the corresponding Weaver slot is erased, and a device factory reset erases all Weaver slots. The secure element also protects against insider attacks by preventing firmware updates prior to authenticating with the owner profile.

The secure element enforces standard delays for encryption key derivation:

• 0 to 4 failed attempts: no delay
• 5 failed attempts: 30 second delay
• 6 to 9 failed attempts: no delay
• 10 to 29 failed attempts: 30 second delay
• 30 to 139 failed attempts: 30 × 2⌊(n – 30) ÷ 10⌋ where n is the number of failed attempts. This means the delay doubles after every 10 attempts. There’s a 30 second delay after 30 failed attempts, 60s after 40, 120s after 50, 240s after 60, 480s after 70, 960s after 80, 1920s after 90, 3840s after 100, 7680s after 110, 15360s after 120 and 30720s after 130
• 140 or more failed attempts: 86400 second delay (1 day)

Invalid input that exceeds the UI’s minimum or maximum length limits will not result in an attempt at authentication or key derivation.

Only Weaver-enabled devices are officially supported by OryonOS. The fallback implementation for devices that do not have it is beyond the scope of this FAQ.

The TEE uses the password token, Weaver token, and other values such as the OS verified boot key as inputs to a hardware-bound key derivation algorithm provided by the SoC. The general idea is for the SoC to perform hardware-accelerated key derivation using an algorithm such as AES or HMAC keyed with a hard-wired hardware key that is inaccessible to software or firmware. This is intended to prevent a brute force attack from being offloaded onto more powerful hardware without requiring an expensive process of extracting the hardware key from the SoC.

To provide an additional layer of encryption, many apps use the hardware keystore, their own encryption implementation, or a combination of the two. To keep their data at rest when the profile is locked but not logged out, an app can use the hardware keystore to encrypt their data with a key that is only available when the device is unlocked.

6. Can apps spy on the clipboard or insert content into it in the background?

Only the configured default input method editor (your preferred keyboard) and the currently focused app can access the clipboard in Android 10. Apps that do not have focus cannot access the clipboard. This is a stricter restriction than preventing apps in the background from accessing it, because an app in the foreground or a foreground service cannot access it, only the currently focused foreground app. Clipboard managers must be implemented by the keyboard that the user has set as the default.

As a much earlier and slightly less strict implementation of this feature, OryonOS previously restricted background clipboard access. It offered a toggle for users to whitelist clipboard managers, which is no longer required now that keyboards are expected to do so.

When an app reads clipboard content set by another app, the user is notified as of Android 12. This notice is enabled by default and can be disabled by going to Settings Privacy Show clipboard access.

7. Apps access to hardware identifiers

Apps cannot obtain permission to access non-resettable hardware identifiers such as serial numbers, MAC addresses, IMEIs/MEIDs, SIM card serial numbers, and subscriber IDs as of Android 10. Only privileged apps with READ PRIVILEGED PHONE STATE whitelisted in the base system can access these hardware identifiers. For compatibility, apps targeting Android 10 will receive a SecurityException, while older apps will receive an empty value.

Because these restrictions became standard, OryonOS has only made a minor change to remove a legacy form of serial number access by legacy apps that was still present for compatibility. It used to require more extensive changes, such as restricting access to the serial number, but those limitations are now standard.

Software applications can determine the model of the device (such as a Pixel 6) either directly or indirectly by examining the hardware and software properties. There is no way around this unless the operating system supports running apps in a virtual machine with limited functionality and hardware acceleration. Hiding the CPU/SoC model would necessitate not even using basic hardware virtualization support, and these things would almost certainly still be detectable through performance measurements.

8. Non-hardware identifiers

Apps cannot directly identify the installation of the OS on the hardware, in addition to not being able to identify the hardware. Apps are only exposed to a small portion of the OS configuration, and there isn’t much for device owners to change that could identify their installation. Apps can detect that they are running on OryonOS by using the privacy and security features, imposing additional restrictions and hardening them against further exploitation. Apps can use their app data to identify their own app installation and can directly (until that is removed) or indirectly identify a profile.

User Profiles should be used when distinct identities are desired. Profiles can be used as ephemeral identities for a short period of time by creating them for a specific purpose and then deleting them. The majority of the rest of this answer only provides extra technical details, so you can quit reading here if you only want an outline and actionable advice (i.e. use profiles as identities not inherently tied to each other).

Configured locale, time zone, network country code, whether the dark theme is enabled, and other similar global settings are examples of global OS configuration available to apps. An app could use a combination of these things in an attempt to identify the installation, similar to how web sites fingerprint extension and browser configuration / state. All of these things change at runtime and can be changed, but some, like the ones listed above, are unlikely to change in practice after the initial setup of the device. OryonOS will almost certainly add more restrictions in this area, as well as a couple of toggles for certain cases, such as time zones, to use a standard value instead.

Applications can generate their own 128-bit or larger random value and use it as an app installation identifier. Apps can create data in their app-specific external storage directory by default, and in the legacy storage model prior to API 29, that data persists after the app is uninstalled, so it can be used to store an ID that persists through the app being uninstalled and reinstalled. External storage, on the other hand, is under the user’s control, and the user can delete this data at any time, including after uninstalling the app. When an app is uninstalled, this data is automatically deleted in the modern storage model.

The ANDROID ID string is a 64-bit random number that is unique to each profile and app signing key combination. Because of the possibility of collisions, the 64-bit limitation means it isn’t particularly useful. It is associated with the lifetime of profiles and does not survive profile deletion or a factory reset. This is analogous to a legacy storage model app storing a 64-bit random value in the app-specific external storage directory. OryonOS will most likely change this in the future to be tied to the lifetime of app installations rather than profiles. An app could still track the profile’s identity using data you give it access to or data another app chooses to share with them.

Because the advertising ID is a Google Play services feature that is not included in the standard Android API, it is not included in OryonOS. Each profile has its own advertising ID. It isn’t unique to each app signing key like ANDROID ID, but that’s irrelevant because apps in the same profile can communicate with each other with mutual consent. It’s similar to ANDROID ID, but it has a 128-bit value, which provides a strong cryptographic guarantee against collisions, though a device tampering with apps could set it to the same value used in another profile. The advertising ID is exposed through the Settings app and can be reset to a new random value, as opposed to ANDROID ID, which remains the same for the lifetime of the profile, but apps can tie it to the previous ID because they can detect that it changed via their own ID in their app data.

Applications do not have default access to user data and cannot access the data of other apps unless those apps go out of their way to share it with them. If apps are given read access to user data such as media or contacts, they may be able to identify the profile. If apps are given write access to user data, they can tag it in order to keep track of the profile. Previously, apps had little reason to do this because they were able to persist data through uninstall and reinstallation by default. Because of the modern storage model, they must request access to user data in order to do so.

Because ANDROID ID exists, they don’t need to worry about it for the time being, but that will change on OryonOS and will most likely change for baseline Android as well. However, because the OS’s application model is designed to support communication between apps within the same profile but never between them, profiles are the only way to provide a strong assurance of separate identities.

9. What action does OryonOS take in the face of cellular tracking, interception, and silent SMS?

OryonOS always regards networks as hostile and avoids putting its trust in them. It excludes a number of carrier apps that are included in the stock OS and provide carriers with varying levels of administrative access above and beyond standard carrier configuration. OryonOS also avoids cellular network trust in other ways, such as by providing a secure network time update implementation rather than relying on the cellular network for this. Time is important, and it can be used to avoid security checks when a certificate or key expires.

Cellular networks use protocols that are inherently insecure and have a large number of trusted parties. Even if connection interception or other man-in-the-middle attacks are not currently taking place, the network is still untrusted and data should not be sent unencrypted.

Authenticated transport encryption, such as HTTPS for web sites, eliminates the need to trust the cellular network. End-to-end encrypted protocols, such as the Signal messaging protocol, avoid trusting servers as well. For our services, OryonOS employs authenticated encryption with sophisticated protocols, forward secrecy, and strong cipher configurations. We highly suggest apps that take a reasonable approach in this area.

Legacy calls and texts must be avoided because they are insecure and rely on the carrier / network, as well as having poor security against third parties. Attempting to detect some forms of interception rather than addressing the root cause (non – encrypted services / data transfer) would be destined for failure.

Connecting to your carrier’s network is totally dependent on you identifying yourself to it and anyone with administrative access. When you enable airplane mode, the cellular radio transmit and receive capabilities are completely disabled, preventing your phone from being reached from the cellular network and preventing your carrier (and anyone impersonating them) from tracking the device via the cellular radio. Other functionality, such as Wi-Fi and GPS, is implemented in the baseband, but each of these components is sandboxed and independent of the others. Enabling airplane mode deactivates the cellular radio, but Wi-Fi can be re-enabled and used without re-activating the cellular radio. This enables the device to be used solely as a Wi-Fi device.

OryonOS’s addition of an LTE-only mode is solely for the purpose of reducing attack surface. It should not be misconstrued as a means of transforming the cellular network as something that can be trusted.

OryonOS does not include catchphrases in the absence of a proper threat model and justification. We will not use flawed heuristics to determine when the cellular network can be trusted. These types of features create a false sense of security and foster unwarranted trust in cellular protocols and carrier networks as the default. These also cause false positives, which cause unnecessary concern and fear. To avoid having to rely on an insecure network, use authenticated encryption and airplane mode.

Receiving an SMS is not a good indicator that you are being targeted by your cell carrier, police, or government because anyone on the cell network, including yourself, can send them. Cellular triangulation will occur whether or not SMS texts are sent or received by the phone. Even if an SMS served a useful purpose for tracking, receiving a silent SMS would be similar to receiving unsolicited spam. In fact, sending spam would be more stealthy because it would not trigger alerts for silent SMS but would instead be ignored along with the rest of the spam. Despite, sending text messages or other information is not required or particularly useful for an adversary with appropriate access to track devices connected to a network.

10. How do the system updates work?

Automatic background updates are implemented by the update system. When there is network connectivity, it checks for updates every four hours and then downloads and installs updates in the background. You don’t have to worry about interrupting it because it will resume where it left off if downloads are interrupted. Similarly, interrupting the installation poses no risk because updates are installed to a secondary installation of OryonOS, which only becomes active after the update is complete. When the update is finished, you will receive a notification and will only need to reboot using the button in the notification or by performing a normal reboot.

When a direct path from the installed version to the latest version is available, the updater will use incremental (delta) updates to download only changes rather than the entire OS. As long as you maintain regular network connectivity and reboot when prompted, you’ll almost always be on one of the previous couple versions of the OS, which will minimize bandwidth usage because incrementals will always be available.

The updater runs while the device is locked / idle, including before the first unlock, because it is explicitly designed to run before user data decryption.

11. What is the OryonOS service’s privacy policy?

For all users of our publicly available services, not just those who opt out of tracking via Do Not Track, OryonOS services adhere to the EFF’s privacy-friendly Do Not Track (DNT) policy. Our policy is the same, except that “DNT User” has been redefined as “user” to cover any user. This serves as a uniform privacy policy for all of our government services:

……………………

Our policy implementation consists primarily of ensuring that our servers only keep logs for 10 days. In practice, we adhere to much stricter privacy guidelines than those outlined in the EFF policy. However, we do not want to create our own complex, ad hoc privacy policy rather than reusing a sensible one that has been thoroughly thought out by experts.

Because it is only used internally by OryonOS developers, our mail server (mail.Oryonos.org) is not provided as a public service and does not have a privacy policy.

12. Which DNS servers are typically used by default?

By default, the operating system makes use of the DNS servers provided by the network. Dynamic IP configuration is commonly used to auto-configure the client on the network. IPv4 DNS servers are obtained through DHCP, while IPv6 DNS servers are obtained through RDNSS. The DNS servers for a static IP configuration are manually configured as part of the static configuration.

A VPN provides a network layered on top of the underlying networks, and the OS uses the DNS servers provided by the VPN for everything other than resolving the VPN’s IP address and performing network connectivity checks on each of the underlying networks in addition to the VPN itself.

The best way to blend in with other users is to use the network’s DNS servers. Because of a non-default DNS configuration, networks and websites can fingerprint and track users. The network-provided DNS servers are our recommendation for general-purpose use.

13. What kinds of VPN and Tor support are there?

VPNs can be set up in Settings Network & Internet VPN. The following protocols are supported: IKEv2/IPSec MSCHAPv2, IKEv2/IPSec PSK, and IKEv2/IPSec RSA. Applications can also provide user space VPN implementations, and the open source apps Orbot (Tor), WireGuard, and OpenVPN for Android are recommended.

VPN configurations created with the built-in support can be configured as always-on VPNs in the configuration panel. This will keep the VPN running, reconnecting as needed, and forcing all connections to go through them. An app that provides a VPN service can also be configured to be the always-on VPN via the Settings page. There is also a “Block connections without VPN” toggle for app-based VPN implementations, which is required to prevent breaches when the app’s VPN service is not running.

14. Can software applications keep track of network connections and statistics?

Software applications cannot monitor network connections unless the user enrolls them in an active VPN service. Apps cannot typically access network statistics and cannot request them directly. App-based stats, on the other hand, can be explicitly granted by users as part of access to app usage stats in Settings Apps Special app access Usage access.

15. Is there a firewall in OryonOS?

Yes, OryonOS inherits the Android Open Source Project’s deeply integrated firewall, and is used to implement portions of the security model and various other features.