> Am 08.12.2023 um 18:22 schrieb Paul Boddie <[email protected]>:
>
> On Friday, 8 December 2023 15:40:45 CET H. Nikolaus Schaller wrote:
>> Indeed an interesting approach. But I don't get the benefits. If it is about
>> secure (i.e. end-to-end encrypted) voice and text communication, this can
>> equally securely be done by an open source application running on the app
>> module of two identical devices (which could even be off the shelf). It
>> would also follow the idea to use an unsecure communication
>> channel.
>
> I think the essence of the motivation for this approach is that the
> smartphone
> environment is complicated, opaque and inscrutable (Android or Linux running
> on an SoC with lots of unaudited functionality) where applications could be
> doing all sorts of bad things.
Well, if you put an encryption layer above all these unaudited things in the
application
processor and the worst case can be a denial of service by the unaudited
components.
It is like you can use https over an untrusted ethernet connection and
internet... You
only have to trust your https engine. If you use openssl+wget for that task you
can
audit this shielding layer doing end-to-end encryption without need for a new
hardware
architecture.
So you can write an Android app that does this encryption by itself. At least
for
text messaging (provided no rogue component taps the key strokes - but this
is fully auditable in an architecture like the Openmoko devices were).
> Meanwhile, the core telephony environment is
> simpler, transparent and separated and protected from the untrustworthy
> smartphone environment.
Well, that is not different from the cellular modem architecture with just an AT
command interface, a data channel and an I2S interface for audio is doing.
Except that you can't dial by it directly.
> Thus, the user can treat the smartphone environment like a sandbox, falling
> back to the core environment where they need to be sure that nothing is
> interfering with their communications. It is, I suppose, a bit like the way
> that Ctrl-Alt-Delete on Windows NT is meant to bring the system to a known
> state, ensuring that the user is typing their credentials into a dialogue
> that
> really is operated by the system and not some rogue program.
>
> I don't know how mainstream smartphone architectures address various related
> needs to what this project is addressing. For example, things like emergency
> calls and alerts should be handled at a lower level than some kind of "app",
> and yet the introduction of emergency alert systems that do not work with
> many
> existing smartphones (the one in Norway and other countries, for instance)
> suggests that regulatory oversight of such things has been softened.
Well, they usually either have a separate modem subsystem which does all
dialing incl. calling 911. This subsystem contains all radio control protocols
and has to be certified. Everything else is considered an "application
processor"
and not part of the certification.
To get this certificaition the modem subsystem must run on a separate processor
or the operating system must be audited that everything runs in a safe and
shielded task or thread.
This is likely be the reason why you can't buy Qualcom or Mediatek processors
with integrated wireless functionality. But you can buy radio modules which
contain such a processor and just provide some AT command set. These
are precertified.
>
>> The only thing he has secured a little more is the display, touch and
>> microphone/speaker. But at the moment he wants to allow a bluetooth headset
>> there is an intrusion vector.
>
> I imagine that all such add-ons might be untrusted in this scheme.
>
>> Anyways thanks for making us known to our community.
>
> No problem! It provides some inspiration and guidance, I suppose.
Indeed.
Best regards,
Nikolaus
_______________________________________________
Community mailing list
[email protected]
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org
