Conversation

We're hopeful the recent attention will help us with finding hardware partners with aligned goals. It's a requirement for the devices to be at least as secure as a Pixel. That includes a modern mobile SoC and a comparable secure element to the Titan M implementing the same APIs.

109

GrapheneOS

@GrapheneOS

Feb 1, 2021

Initially, it doesn't need to be better. It's difficult enough to produce a device meeting the same standards without severe privacy or security regressions. We're not interested in having our brand associated with a device that's marketed as private and secure but is worse off.

GrapheneOS

@GrapheneOS

Feb 1, 2021

The setup we want to have isn't far from what Google was doing with Nexus devices. GrapheneOS needs substantial input into the design and implementation of devices. They'll use our signing keys for boot chain, stock OS verified boot key, etc. Pixels set the baseline standards.

GrapheneOS

@GrapheneOS

Feb 2, 2021

Some additions to the secure element APIs would make sense and a 'Sensors Off' switch disabling all sensors usable for audio recording (microphones, cameras, gyroscopes, accelerometers, compass, barometer, etc.) for mitigating a compromised device would be a nice frill to add.

Replying to

does it mean that on Pixels + GrapheneOS, when an app has "sensors access", it has an indirect access to audio recording, even if if microphone permission is off ?

Replying to

and

Sensors like gyroscopes and accelerometers can be used for recording audio. Android doesn't give apps high frequency polling of sensors and limits their usage in the background: developer.android.com/guide/topics/s. The kill switch threat model is that the device has been compromised though.

developer.android.com

Sensors Overview | Android Developers

Replying to

and

That means for the kill switch threat model, there is no limitation on polling sensors, and they make much better microphones than they do with that limitation. Even with the limitation, they can perform crude audio recording. Sound is vibration. Gyroscopes, etc. are crude mics.

Replying to

and

Custom hardware isn't going to change anything about the permission model used in the OS or the semantics for it. It seems like you're misinterpreting this as an issue with Pixels. GrapheneOS adds the Sensors permission because they leak crude forms of audio, location, etc.

Replying to

and

I think you are mixing up questions : I never spoke about custom hardware, and I didn't stated it was an issue for grapheneos project. Just asked a genuine question (that may look naive for an infosec expert) about the reality behind the wording "microphone permission".

Replying to

and

and thanks to your detailed answer, I know now it's a 'misleading' wording, at least for every android based OS.

Replying to

and

The microphone permission controls access to the microphones. It's only ever possible to permit it for an app in the foreground. It's not specific to Android but rather is also how this is designed in iOS, web browsers and elsewhere. Motion sensors, etc. are done separately.

12:19 AM · Feb 3, 2021Twitter Web App

Replying to

and

The issue with motion sensors and various other sensors is that they essentially act as a form of side channel. They leak crude information about location, sound and other aspects of the environment through what they provide. Android and iOS throttle polling to mitigate this.

Replying to

and

If the device is compromised, then the OS enforced throttling for polling isn't relevant. For the threat model of a hardware kill switch, nothing enforced by the OS is relevant. A mic kill switch alone doesn't work. High freq polling of motion sensors makes them decent mics.

Show replies