NitroKey disappoints me | Hacker News Reader

NitroKey disappoints me

blog.brixit.nl

279 pointscunidev66 comments

Maybe NitroKey are surfacing something useful and potentially concerning, but they way they do it is so cheap that it completely turns me off their brand. It’s a bunch of negativity-hype with a “so buy our phone” tacked on.

If you handed a Nitrophone to any competent security researcher, I bet they’d find a ton of issues. Same with the NitroKey; that feature list is far too extensive to not have issues.

So everyone is considering the same points: are you saying this in knowledge of their published audits?

I am

Edit: to elaborate, I think it’s great that they published audits, that should be a minimum baseline but in fact it’s a fairly rare thing at this point. Also Cure53 are no joke, they have some great people who generally do good work.

That said, having spent a decade doing security assessments in a past life, they’re point in time and always have a particular scope and are time-limited. A researcher or adversary has more time, a broader (infact infinite) scope, and lacks a lot of the restrictions of a formal security assessment.

Aren't Nitrophones just rebranded GrapheneOS Pixels?

Yes they provide the service of flashing GrapheneOS onto a Pixel for people who are not confident enough to do it themselves. I think they kick back some of the revenue to the GrapheneOS project. It is a needed service for people who want the most secure, private, yet functional phone but not the hassle of setting it up.

I remember seeing a pen-test that was done way back in the mid aughts that identified a bunch of vulnerabilities. It was so long ago, I wonder if they were mitigated or just given lip service.

EDIT: I found it. Pretty interesting read: https://cure53.de/pentest-report_nitrokey.pdf

This penetration test against the Nitrokey Storage firmware, as well as the Nitrokey desktop app, was performed by a team of three penetration-testers and took eleven days in total to complete. The test is part of a larger series of security assessments. In later phases, security-focused assignments will include tests against the hardware itself, alongside detailed look into other models of the Nitrokey and its accompanying applications and tools.

I am just sad with the modern era of marketing and PR.

It's been this way for decades, and we thought it was tacky even back then.

> surfacing

IZAT NLP concerns have been known for many years now, my DivestOS hasn't included it for 6+ years: https://gitlab.com/divested-mobile/divestos-build/-/commit/a...

Related ongoing thread:

Smartphones with Qualcomm chip secretly send personal data to Qualcomm - https://news.ycombinator.com/item?id=35698547 - April 2023 (263 comments)

I've criticized the original article for lack of information here: https://news.ycombinator.com/item?id=35698547#35703662

However, this blog post takes it too far:

> It proceeds to not show the contents of this HTTP request because it would show that it's not at all interesting. It does not contain any private data.

You don't know that, nor do you take any steps to actually prove your claim. This blog post is just as bad as the original post for not providing any evidence to your claims.

To add to that: OP seems to summarize the HN comments section without even citing it.

I'm double disappointed :)

I have not even seen the HN comment section before writing this post

Also to mention... A-GPS is extremely crucial to the underpinnings of the e911 system. Having rapid fixes means quicker positioning data being sent over the wire to the 911 center.

It helps, it's not extremely crucial. There are other methods that don't require the handset's cooperation:

- https://www.mpirical.com/glossary/lmu-location-measurement-u...

- https://www.etsi.org/deliver/etsi_ts/136100_136199/136111/11...

all these methods aren't super reliable. The combination of all of them is required for what people have come to expect from GPS.

Also people want GPS to work seamlessly in locations where GPS is unreliable. Dense urban canyons, inside big buildings and a myriad of other locations. AGPS is absolutely necessary for this.

Without this, people will wonder why the phone's "GPS" is bad (it takes a long time to get position and it is inaccurate in many cases).

The author didn't address the list of things the devices allegedly sent when downloading A-GPS files, from the original article:

1. Unique ID

2. Chipset name

3. Chipset serial number

5. XTRA software version

6. Mobile country code

7. Mobile network code (allowing identification of country and wireless operator)

8. Type of operating system and version

9. Device make and model

10. Time since the last boot of the application processor and modem

11. List of the software on the device

12. IP address

That's not a list of things allegedly sent. That's a list the lawyers put in a legal document to not get sued in case it happens.

a-gps/supl ("xtra"?) and qcoms izat api (in-building location services using indeed accesspoint info) are mixed in both HN threads. If izat triggers in customroms and sends plain http needs to be shown, but the .so libs are on device firmware partitions if not actively deleted. On older devices lineage mounts them unmodified from stockrom into /vendor/

The author claims that none of the above information is actually sent, other than the IP address which is unavoidable to download a static file. I don't know who is right because I haven't seen the actual intercepted HTTP traffic.

It is odd that neither article quotes from the policies linked from the domain they're talking about.

I think the relevant section is "Qualcomm GNSS Assistance Service" on https://www.qualcomm.com/site/privacy/services

> The Qualcomm GNSS Assistance Service downloads to your device a data file from QTI containing the predicted orbits of the Global Navigation Satellite System (GNSS) satellites. The Qualcomm GNSS Assistance Service also uploads a small amount of data to us comprised of: a randomly generated unique software ID that is not associated to you or to other IDs, the chipset name and serial number, the Qualcomm GNSS Assistance Service software version, the mobile country code(s) and network code(s) (allowing identification of country and wireless operator), the type of operating system and version, device make and model, the date and time of connection to the server, the time since the last boot of the application processor and modem, and a list of QTI software on the device.

> As with any internet connection, we will also receive the IP address the device used to send us data. We use the data we collect to evaluate, maintain, and improve the performance of our systems and to determine general location (but not specific geolocation). We do not sell (as that term is defined under the California Consumer Privacy Act) the full IP address, unique software ID, or chipset serial number, and we share personal data only under the limited circumstances described in this Policy.

I didn't ask about what the policy document says, but about what is actually transferred by the chip itself, independently of the OS. Since it's not encrypted this can be determined.

Okay but I don't see why you're so skeptical of the policy.

This is all normal telemetry data roughly analogous to what most websites collect. Why are you assuming they're probably collecting much less?

Because policy documents are written by lawyers to cover the companies ass for every eventuality. There is a different motivation here.

The code is written by engineers to either solve a problem, or spy on the users. The policy document does not disambiguate between the two.

Especially because the service required to capture/collect these metrics would be several orders of magnitude more complex than the service required to serve a single static file.

Not really?

Include them in the web server logs of the system serving the static file and call it a day.

That’s pretty basic.

> the chipset name and serial number

That’s actually pretty damning. A bunch of (chipset serial number, IP) pairs can track users very effectively over time. And saying they don’t sell the serial number or IP is mostly worthless — they could easily sell equivalent information.

Well, a device can get the time via GPS only.

If for whatever reason the system's time is just SO wrong then there's a change the HTTPS connection might fail because of certificate not valid yet / expired.

For this I think it's OK for it to be served over HTTP.

It also allows for transparent carrier caching, might even be why it's HTTP in the first place.

But is this a file that you want to have cached?

Honest question! Not sure how often this is updated.

Every 10 minutes according to the article

The almanac is broadcast every 12.5 minutes. It is only updated about once a week.

Reminds me of your typical "Windows support" impersonator telling people to look at all the spooky errors and warnings in Event Viewer and "all I need is for you to install this remote access tool and I can fix all your problems for you".

Was just looking at NitroKey after realizing my SoloKey v2[1] won't come for yet another few months.

Given that they use similar firmware, the headline scared me a bit. However the article is about their marketing of an entirely different device, not their new Yubikey replacement.

The wait continues... not super-surprised though, crowd funding hardware is super-risky and I knew that.

[1]: https://solokeys.com/

I was very disappointed in that Kickstarter. Yubikey ran a 54% off discount May 4th last year and not knowing when I would get my v2 SoloKeys, I purchased two. I had them within the week and have since integrated them into all my accounts.

I debated backing out of the Kickstarter as the Yubikeys were working so well for me, but decided to stick with it and see what the SoloKey experience would be like. Yeah, disappointing. I ordered USB-A and USB-C keys. The USB-A key doesn't make a good connection with the USB port. It needs to be carefully held to register with the OS, otherwise it doesn't get power.

There's OnlyKey. Mine have been fine.

I guess I was very lucky to get my solokey v2s a few month ago. I do like them. I am a bit disappointed that they have problems for other backers.

Why not try Librem Key (which is rebranded NitroKey with free firmware)?

So, presumably if I bought one of their phones and turned it on, I would wait ten minutes to get a GPS fix instead of it using a almanac and working out the lat and long of three cell towers at certain signal strength?

Does anyone know if it's possible to get at this info from user side ? Some API access? sounds fun

You don't even need the cell towers. You need _very_ good gps reception though, so outside without tall structures nearby. Then you have the issue that you need to keep the GPS active enough to keep the almanac updated. Which is usually not happening due to power management.

IP packets should not be sent or received behind our backs, and certainly firmware should not be bypassing the operating system to do this.

Whether it is useful for A-GPS does not matter. It must be done on top of the operating system or not done at all.

> IP packets should not be sent or received behind our backs

I like this idea in principle, but I have bad news for you if you ever want to own literally any modern device - phone, laptop, tablet, car, TV, rice cooker etc

The only solution is some kind of network-level allowlisting which would be impossible to maintain, and stop working the second you’re outside a known network (ie LTE)

This is not even done by firmware, it's just part of qualcomms android userspace.

I see no reason why Android shouldn't handle A-GPS itself.

Qualcomm's userspace shouldn't be doing this.

As far as I understand, the request and response formats are proprietary. Android could define a HAL for that though, and proxy requests and responses.

or forbid it altogether, and fully handle A-GPS itself.

This isn't happening behind your back. A-GPS isn't a secret feature in phones.

No! I want every single request my phone might make explained to me in advance!

you jest, but this is actually fine.

do this via mighty-snitch[1] on any postmarketos phone. any network request passing through the linux kernel gets filtered.

still hosed if it’s hardware level nonsense unfortunately.

the only reason i’m not daily driving postmarketos is lack of gpu acceleration for firefox. hopefully soon!

1. https://github.com/nathants/mighty-snitch

This is exactly what I want.

Are A-GPS files tied to location or the same for everyone? Hopefully, the latter.

I'm fairly sure they're just static files

How would the server even know the client’s location? By IP address? That would make GPS work poorly when using a VPN or a wireless network with unusual routing.

edit: y’all are reading this backwards. My point is that the Qualcomm server does not know the location of the client and therefore cannot usefully send anything other than a static file.

The data isn't location based, it's the same for everyone. The GPS control center updates it once an hour or so, but it's applicable globally. As the article explains, GPS satellites broadcast it, but at a low bitrate so it takes a long time to receive. Much faster to just download it from the internet. Because of the architecture of GPS in phones (which is basically a historic artifact, the chipset is expected to provide NMEA sentences and the OS doesn't want to be more deeply involved than that) AGPS needs to happen at a fairly low level.

In principle AGPS can send the GPS radio data to a remote server and have the server do the difficult maths then send back your position. This is apparently a thing somebody actually designed, however since "doing difficult maths" is now very cheap you'd obviously just do that on the phone.

It's not that unreasonable an assumption. Qualcomm offers a different opt-in service under the same name that does use location data.

Basically your phone uploads sensor data like cell tower strength and WiFi strength, and their service estimates your location. The your device locally uses gyro/accelerometer to fine-tune.

See Qualcomm Location Service (formerly “IZat Location Services” or “IZat”) on https://www.qualcomm.com/site/privacy/services

This is basically a copy of a signal broadcast worldwide by the GPS satellites. Just static data.

You can transfer a lot of information in a request, it's one of the oldest tricks in the book.

Whilst I also had a bad taste in my mouth once I got to them shilling their product (it was a double-check - wait a sec this Nitro phone they're talking about it's their own bloody phone?) that doesn't change the fact that this unexpected behaviour is a problem.

What we need to see is the actual HTTP requests, either from Nitro or - even better - from a third party who verify it.

Nitro's product also does it, but maybe they download the file from themselves or another vendor. Every internet-connected GPS device does it, and this has been the case since even before smartphones took off. If they don't, first fix in a day will take 10-15 minutes of solid reception.

Some GPS chipsets will perform A-GPS internally using a baseband IP stack, but most smartphones actually don't and expect a daemon to handle it since the OS has more sophisticated ways of deciding what network connection to use for the download. This is the most common case for Android, the OS downloads the file and uses a kernel module to provide it to the GPS chipset. The chipset vendors, including Qualcomm here, provide this service as part of their userspace components.

An IIOT LTE module I use has an onboard IP stack and AGPS implementation since it's intended for use in contexts where there isn't necessarily a conventional OS connected to it, maybe just a serial data logger or whatever. The A-GPS requests it makes contain so little data it's a bit comical, the bare minimum for a valid HTTP request. Another reason it's nice to have the OS do it is since that tends to get you access to a more complete HTTP library.

Thanks (and to Maarten too, for some reason I can't reply to his post) that explains it.

Nitro have made rather large claims; if they're real security experts then they need to share the details or GTFO.

You don't need a third party, you just need to check your network traffic. The issue is that this request is not sent very often because this data is valid pretty long.

But it's basically just fetching https://xtrapath4.izatcloud.net/xtra2.bin with cron (or some other subdomain, depending on the SoC) and uploading that to the gps module so it has atmospheric corrections.

Static data for the entire system. A-GPS files are just a digital ephemeris[1], a form of trajectory tables for the satellites over (upcoming) time, so it knows when to expect certain satellites (and thus certain transponder frequencies to pick first in its search for signals to lock onto and triangulate from).

[1] https://en.wikipedia.org/wiki/Ephemeris

A-GPS provides a current almanac, showing where all the satellites actually are. Without it, a cold start requires hunting for signals across a much wider range. As I understand it, older GPS receivers rely on finding a single satellite and waiting to acquire a full almanac from it while smartphones have enough compute to probably get a lock on multiple satellites without a complete dataset. The satellites will eventually broadcast the complete almanac and ephemerides, so a warm start shouldn't take as long.

D-GPS uses the known location and current readings from a nearby fixed receiver to increase the accuracy of your receiver, and does rely on knowing that you're in the vicinity, but it's not a feature of consumer phones.

/e/OS answered at /e/OS answered at https://community.e.foundation/t/qualcomm-chipsets-data-coll...

Straight, concise, clear and to the point.

Thanks!

Not to mention that AGPS is decades old by now. How many of you fell for the original article's narrative?

Reply on news.ycombinator.com