Using Pseudonymous Messaging Accounts on Qubes

General Discussion
2

Interesting topic! I can see how this might be a problem. For you, the primary reasoning is security (as it would be for me) but others might require that anonimity that comes from not being tied to a device that constantly broadcasts the location.

Signal

Fortunately, this can be achieved with Signal - an Android emulator is fully optional. You’ll need an app that is able to register as the primary device, rather than a ‘linked device’. Being a keyboard warrior myself, I highly prefer the CLI. For Signal, there is the signal-cli. For a nice TUI, consider something like scli.

I have no idea if and how it can be setup with the Signal Desktop application as a ‘linked device’.

Using a cellphone

This might not be a privilege that anyone can afford - another possible solution might be to use a Google Pixel (that is still supported) and flash GrapheneOS onto it. It makes use of IOMMU (like VT-d) to keep the baseband SoC isolated from the rest of the system. Enabling the flightmode and enabling WiFi after should offer a reasonably secure model.

And more

Another route might be to get a USB dongle, throw a sim card in and use it solely for receiving the activation text messages. I would be cautious as to using VoIP over Tor, because the involved parties need to support in-flight encryption. Unfortunately, TLS is not something that is required for SIP, etc.

I haven’t used WhatsApp for nearly half a decade, so I can’t offer any advise or insights. Does WhatsApp Web or a desktop app (if any) still require the primary phone app to be online and reachable?

2 Likes
3

Could something like jmp.chat help with the 2fa? Tried looking into setting something up like this myself but had no idea how.

4

Thanks for collaborating.

Signal

As best I understand it, you can sign up via desktop cli signal, but you still need a number to recieve a text/call to and register via, even if desktop is not the main device. This number can be a mobile/landline/voip/other, decide based on your threat model. You can then set a passcode for your signal account to preserve the associated number (even if you’re only displayed as and searchable by a user tag with no number), but the passcode will default after 7 days of inactivity so someone else can use the number. Users much either maintain a number to re-authenticate through (be that a real phone or voip/sms forward solution) OR must be sure to use the account at least once every 7 days.

Using a cellphone

In my case the only form of cellphone i’d be using would be a dumb phone with battery removed for emergencies. Or maybe an older smartphone with all antennas removed so that it was airgapped. No GSM, no wifi/bluetooth, no rfid. For me geolocation is a massive part of my threat model, but not anonymity. An airgapped smartphone would be a useful camera, calculator, pocket device. Good for currency exchange conversions, voice recording etc. Maybe as a portable media player and external storage. (Think about trying to get the highest degree of compartmentalisation with the maximum degree of functionality and portability. You don’t want to carry an ipod and calculator and cheap camera if you can just use a modified iphone safely)

Graphene OS sounds great. I saw posts in this forum about people hoping to port it to Qubes but no offerings as of yet. Back to a question from before: can anyone comment on android emulators being able to ‘phone home’? I can’t imagine the emulator VM would gain access outside of itself so can’t expose other VMs or home wifi information, but if forced to register the device then google still has some talons in where they’re not wanted. My understanding of network tunneling isn’t great yet, I don’t know if google would get access to your IP address, for instance. Identity anonymity isn’t my concern, but geographical anonymity is.

USB Dongle (and geolocation)

USB dongle is an option, but that does tie you to SS7 network for messages. Safer option with dongles is almost certainly a data only sim, but then no verification texts. If using voice/text enabled sim, a victim of simjacker or pegasus attack at least won’t suffer precise gps tracking as the dongle won’t have gps antenna (check yours). (refer to Rob Braxman video on privacy experiments for notes on travel routers and using your devices without a simcard directly attached) For me, location is everything, anonymity and encryption are almost irrelevant, but nice to have.

Whatsapp

The most convenient, and the most dangerous. The one that gets your number uploaded to other peoples contact lists without your consent; it has no option to disguise your phone number. Should definitely only be used with a proxy/voip number to register- reduce risks of SS7 based attacks. Still not ideal. Whatsapp is undoubtedly the biggest risk.

Patching into SS7 network

In the instance where you have to contact a normal phone number maybe it’s best to use google/skype type voip number to call with a withheld number and hope recipient is within tower range or leave a voicemail (maybe voip protocols recognise if someone has wifi calling enabled- can anyone comment?).

Ideals vs Compromise

Compel important contacts to get signal on their device, more likely to succeed than getting them to use wickr.

Decide for yourself if you’ll accept use of a real phone to register your messaging/calling accounts. If all you want is the functionality for use/testing in qubes, i’m sure this thread will still be applicable once it’s populated with answers, and you can forget the voip anonymous signup part.

Encryption and Anonymity Actually of least importance in my threat model. I assume all other devices are untrusted, so do not disclose locations or other specifics. If someone can read my chats, all they’ll see is that i’m keeping in contact with friends. When i introduce a professional role to this mix, encryption becomes more important. The scales slide for each of us contextually as we move through life.

1 Like
5

jmp.chat

Can you give me and the other readers a quick crash course on what that is and what it’ll achieve if it works as intended?

6

Wickr

For anyone reading: installing wickr in a standalone qube is really as simple as a few commands. No complex networking or crafty workarounds. You can install it in a template but i’ve not been able to get the wickrme install to carry over into the appqube. Apparently there is some bind dirs magic but I’ve not tried to learn yet. Let us know if you make that work. See whonix forums also about issues with persistency of app installs like wickr in qubes-whonix.

I won’t give you the actual commands here, but it’s simple: update of target or template qube, install qubes-snapd-helper, install snapd, install core, install wickr.

7

Hi @anon59741345, I tried to distill the title of the topic to keep the discussion qubes-focused (the previous title was: Never touch a cell phone again’ OR ‘Registering with whatsapp/signal etc via android emulator and using voip phone number’).

1 Like
8

Sounds good to me dude. Am also going to revise my first post and trim it down a little.

9

You need a - any - phone number - it doesn’t have to be a mobile number, you can enter a landline or VoIP number and have the registration provider call you with the verification code. This might be different for other messaging applications - but this is how Signal works.

Regarding the Signal PIN (registration lock): it does expire after seven days of inactivity. But that activity can also be a linked device fetching messages - it does not need to be a smartphone being active on your Signal account. Personally, I fail to see why anyone would register for Signal and then not use the service for seven days (or longer, just make sure you are the sole person to have access to the phone number, at the very least for security reasons).

Unlikely to happen - as running GrapheneOS virtualized or emulated defeats the purpose. Any effort to ‘port’ it to Qubes will involve disabling security features of GrapheneOS.

It does. But if you are going to use it solely to receive verification texts, it is an action initiated by you. You can connect the USB dongle only when you need to use it - or barely enough to maintain the ownership of the number linked to the SIM card.

And connect it to a disposable VM to acquire the text.

Going to be blunt here and rephrasing it as: should never be used.

10

Thanks h3artbl33d,

You’re right, it can be any number. Will edit the above for accuracy. As for maintaining the signal account, in my case would hopefully happen through means other than via an actual phone.

Thanks for the heads up about GrapheneOS being rendered inert when virtualized. Are there no benefits over android emulation in terms of stopping google telemetry? can you elaborate?

USB dongle to read texts in disposable VM is a good shout. When used with qubes on a prepaid sim, popping up on the network every now and then might not be the worst, but still something to be aware of.

I agree, whatsapp should be avoided.

1 Like
11

It can be done. I have several Signal accounts (opsec, different identities) including two accounts not tied to an actual phone at all.

The best you can do in terms of stopping Google Telemetry is using GrapheneOS - in contrast to other Android OS’es, it really doesn’t share any data with Google, whatsoever. The project does support (Sandboxed/Unprivileged) Google Play - but you have to explicitly install it.

Virtualization means you can’t use full verified boot (…and thus no attestation), can’t use a secure enclave, hardened_malloc leverages hardware capabilities to increase defenses - which will also be unavailable. And much, much more. But I’ll leave that up for your research :slight_smile:

Point being: I don’t feel like throwing any time in on porting it over - because it makes no sense. And I wouldn’t use a port for the exact same reasons.

It depends on the situation, requirements, preferences and willingness to make concessions - but from a technical viewpoint you should be able to live, just be and partake in society without using a SIM card (or SS7 for that matter).

Getting a bit more philosophical here: messaging is a means to an end. I’d argue that the ‘goal’ is to connect with other humans. Meeting the other end, face to face, without involving technology, might be even more satisfactory.

‘Social’ media and instant messaging has made the world more distant, darker. Lets turn the tide, remember that we are human and not use technology as a substitute for everything.

12
Offtopic to Qubes

All of this strongly suggests that Librem 5 smartphone might be suitable for you. It has hardware kill switches, removable WiFi and cellular modem, and runs GNU/Linux. Or Pinephone maybe.

13

Have you ever try to use qtox? https://qtox.github.io/

14

What about Session (AppImage) run in a dispVM? You can always recover / regenerate your Session account simply by entering your Session ID (or just make a new one every time).

For mobile usage, what about GrapheneOS without SIM card. Wifi only works fine for me and as backup you can simply setup a hotspot using a friends or an extra simple smart phone.

1 Like
15

Session on Qubes is a great shout. Same drawbacks as wickr- small userbase.

16

Apparently there is funding out there for porting grapheneOS to qubes. Someone obviously thinks it would be worthwhile. If you have the skills why not be the one to do it.

17

Please explain to a noob how this would work, and what the desire is?

Does a laptop already have all the necessary interfaces etc. to emulate a phone? Conceptually I just struggle to picture what a GrapheneOS VM is, is it an emulated mobile environment that allows someone to engage with people and services as though they are on mobile but it offers a greater degree of protection with Graphene?

So it’s the benefits of Graphene with the freedom of Qubes to not have to actually carry a track box with you?

Curious what kind of additional elements you’d need for your laptop to make that work? As you can tell I’m confused :smiley: Ty for any attempt to inform me.

18

There’s lots of threads you can search in here about android emulation. It’s handy for developers, testing, or if you want to use apps which are only accessible on android.

In my case I’d want it for using some specific android only apps. I don’t know if those apps need to be run inside a full emulation or if they can just be nested and run in a container inside a desktopVM- think the movie ‘inception’. I can’t comment on how well something like that works.

Depending on what you’d want out of grapheneOS on Qubes, it sounds like sandboxing between apps on the GrapheneVM might be broken, so you wouldn’t be able to rely on all the features to have the same assurances of privacy and security.

Pretty certain that if your computer can run qubes, it can run an android emulator. There’s probably something to say about the lack of a titan chip in your computer or about how virtualising a secure enclave is oxymoronic and somehow different to the way qubes virtualises machines, but it’s above my paygrade.

Why not just use stock android? In my case my main concern is google telemetry, and I’d hoped a grapheneVM could mitigate that, but I don’t know. Google telemetry might also be a total non-issue when android is emulated, I also don’t know. I haven’t onboarded a phone in so long I don’t even remember if you can do it on android without being forced to register an email, but I’m pretty sure that’s part of the appeal of GrapheneOS or, in this case, Qubes GrapheneVM.

I’m only working through solutions conceptually, I have no skills or experience to implement any ports nor comment on how successful or trustworthy anyone else’s contributions might be.

1 Like
19

Guide on how to create an android qube. I would recommend running either bliss os or android x86 and not anbox as it has sandboxing and other security features disabled, according to this comment. As far as I can tell, there is no graphene os templateVM available for qubes at the moment, nor are there any minimal android templates similar to these.

If you are concerned about SS7 vulnerabilities, I’d recommend using an online SMS PVA service. Here are a couple examples that accept monero and have onion addresses for enhanced privacy & security:

1 Like
20

I would like to add my 2 cents regarding the aspect of android apps’ permissions.
To use Whatsapp as an example, consider a scenario when a user need to use this app (say for business), said user is not concerned by the content that is being transmitted there but IS concerned about having an untrusted app (ie: whatsapp) on her phone, especially considering that this app requires every possible permission on the device.
A nice App-VM on qubes, running android with just that app will solve the problem nicely.
(I struggled today with installing android HPV and gave up after a few hours when the tinkering needed became too much for me. maybe things will change in the future.)

“Security and privacy is NOT ‘all or nothing’ - to each their own” :sunglasses:

1 Like
21

“To use Whatsapp as an example, consider a scenario when a user need to use this app (say for business), said user is not concerned by the content that is being transmitted there but IS concerned about having an untrusted app (ie: whatsapp) on her phone, especially considering that this app requires every possible permission on the device.”

There’s matrix.org out there with bridges for signal, whatsapp, discord and what not. IIRC the bridges still require an Android for registration once.
Also, they terminate the then-not-e2e-anymore encryption. However that should be fine if you don’t care about confidentiality.
Lazy people can even get it as a service for 5$/month or so.

Disclaimer: I haven’t tested it myself yet.

“A nice App-VM on qubes, running android with just that app will solve the problem nicely.”

That would be another interesting solution indeed.