NitroKey disappoints me(blog.brixit.nl) |
NitroKey disappoints me(blog.brixit.nl) |
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.
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...
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.
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.
Smartphones with Qualcomm chip secretly send personal data to Qualcomm - https://news.ycombinator.com/item?id=35698547 - April 2023 (263 comments)
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 :)
- https://www.mpirical.com/glossary/lmu-location-measurement-u...
- https://www.etsi.org/deliver/etsi_ts/136100_136199/136111/11...
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).
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
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.
Honest question! Not sure how often this is updated.
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 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.
Does anyone know if it's possible to get at this info from user side ? Some API access? sounds fun
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.
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)
Qualcomm's userspace shouldn't be doing this.
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.
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.
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.
Thanks!
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.
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!
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
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.
Nitro have made rather large claims; if they're real security experts then they need to share the details or GTFO.
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.
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.
This is all normal telemetry data roughly analogous to what most websites collect. Why are you assuming they're probably collecting much less?
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.
Include them in the web server logs of the system serving the static file and call it a day.
That’s pretty basic.