[HN Gopher] NitroKey disappoints me
___________________________________________________________________
NitroKey disappoints me
Author : cunidev
Score : 128 points
Date : 2023-04-25 21:11 UTC (1 hours ago)
(HTM) web link (blog.brixit.nl)
(TXT) w3m dump (blog.brixit.nl)
| wepple wrote:
| 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.
| DANmode wrote:
| So everyone is considering the same points: are you saying this
| in knowledge of their published audits?
| dchest wrote:
| 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
| MartijnBraam wrote:
| 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.
| not2b wrote:
| 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.
| iudqnolq wrote:
| 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.
| not2b wrote:
| 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.
| iudqnolq wrote:
| 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?
| [deleted]
| s1k3s wrote:
| 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 :)
| MartijnBraam wrote:
| I have not even seen the HN comment section before writing this
| post
| kotaKat wrote:
| 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.
| magicalhippo wrote:
| 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/
| atoponce wrote:
| 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.
| dang wrote:
| Related ongoing thread:
|
| _Smartphones with Qualcomm chip secretly send personal data to
| Qualcomm_ - https://news.ycombinator.com/item?id=35698547 - April
| 2023 (263 comments)
| dmbche wrote:
| Straight, concise, clear and to the point.
|
| Thanks!
| biomcgary wrote:
| Are A-GPS files tied to location or the same for everyone?
| Hopefully, the latter.
| MartijnBraam wrote:
| This is basically a copy of a signal broadcast worldwide by the
| GPS satellites. Just static data.
| radicalbyte wrote:
| 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.
| jcrawfordor wrote:
| 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.
| radicalbyte wrote:
| 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.
| MartijnBraam wrote:
| 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.
| kotaKat wrote:
| 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
| andrewaylett wrote:
| 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.
| VWWHFSfQ wrote:
| I'm fairly sure they're just static files
| amluto wrote:
| 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.
| jcrawfordor wrote:
| 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.
| tialaramex wrote:
| 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.
| iudqnolq wrote:
| 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
| snvzz wrote:
| 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.
| wepple wrote:
| > 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)
| MartijnBraam wrote:
| This is not even done by firmware, it's just part of qualcomms
| android userspace.
| charcircuit wrote:
| This isn't happening behind your back. A-GPS isn't a secret
| feature in phones.
| psychphysic wrote:
| No! I want every single request my phone might make explained
| to me in advance!
| nathants wrote:
| 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
___________________________________________________________________
(page generated 2023-04-25 23:00 UTC)