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.
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.
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.
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.
> 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.
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.
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 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.
> 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.
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.
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.
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.
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/
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.
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.
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.
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
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)
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.
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).
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.
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.
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.
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.
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.
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.
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.