sb0 has quit [Read error: Connection reset by peer]
nicksydney has quit [Read error: Connection reset by peer]
nicksydney has joined #qi-hardware
archang has quit [Ping timeout: 250 seconds]
<DocScrutinizer05>
is *is*, and I hope the usual suspects (CCC, c't, FSFE et al) will start a campaign against such shit, which a lot of companies will join in once they realize their business is going south. AVM (FritzBox) comes to mind, but not only. A *lot* of WLAN devices simply can't comply
<DocScrutinizer05>
and it seems there are not even a good selection of chipsets that would allow building products that could comply
pcercuei has joined #qi-hardware
<DocScrutinizer05>
basically so far the consensus seems to be it basically forbids linux on laptops - up to you to imagine similar usecases where it kicks in
<wpwrak>
reading the FCC requirements, i guess a lot hinges on the definition of "authorized". e.g., one could interpret it such that it is mainly directed against unintended modifications. of course, mentioning DD-WRT points in a different direction. but then that's overly specific anyway.
<wpwrak>
i.e., they could choose to apply a "lenient" interpretation. or not. in any case, even if they don't apply it to the fullest extent for now, they could always change their mind.
<larsc>
any modification that allows the end-user to potentially use the devices in a mode or configuration it was not certified for must be prevented
<wpwrak>
which document are you referring to ?
<larsc>
that's the common interpretation of the regulations
<wpwrak>
i'm more looking for explicit wording
dandon has joined #qi-hardware
<larsc>
the fcc servers with the documents are down
<wpwrak>
so it seems
<larsc>
this is one of the requirements
<larsc>
"What prevents third parties from loading non-US versions of the
<larsc>
software/firmware on the device? Describe in detail how the device is
<larsc>
protected from “flashing” and the installation of third-party firmware such as
<larsc>
DD-WRT."
<DocScrutinizer05>
yep
<DocScrutinizer05>
which is the complete fsckup
<DocScrutinizer05>
it means mandatory tivoization in all devices
<wpwrak>
you could answer that with: 1) we do not produce firmware versions that operate outside the regulatory envelope provided by FCC (likely to be true for many though not all 2.4 GHz band users), 2) firmware binaries have to carry an authorized signature to be accepted (which, as it happens, the user could set. but they didn't as for that.),
<DocScrutinizer05>
you won't get away with that and it already implies you implement tivoization
<wpwrak>
3) DD-WRT is not available for the type of device in question not is it likely to be ported / adapted (applies for example to Anelok)
<wpwrak>
s/didn't as/didn't ask/
<DocScrutinizer05>
anelok for example is not legal according to those rules
<DocScrutinizer05>
users any time can create their own "3rd party sfirmware" and operate the device outside the approved specs
<wpwrak>
DocScrutinizer05: as long as users can control what is allowed or not, signed binaries are likely to be a good thing. so i wouldn't argue against signed binaries per se, but against the disenfranchisement of end users implied there.
<DocScrutinizer05>
no, I generally reject signed binaries
<DocScrutinizer05>
no matter which key infra you install. It can and *will* get abused
<DocScrutinizer05>
and it makes developing stuff a misery for everyone
<DocScrutinizer05>
been there, seen that, Nokia N9 Aegis
<DocScrutinizer05>
signed binaries are *never* in the interest of end users
<DocScrutinizer05>
unless it's a repository signature for integrity and authenticity checks
<wpwrak>
heh, i was just about to point this out :)
<DocScrutinizer05>
even then such signature needs to get handled in userland, not on kernel or even bootloader level
<DocScrutinizer05>
when it _allows_ a scenario where user doesn't have 100% control over the device, then I for sure won't like it
<wpwrak>
such things are often tradeoffs: giving users "100% access" can easily go against their wishes. in this specific case, my plan is to offer levels of openness: locked bootloader for general users, anything goes for VARs/developers/etc. you pick which variant you get.
<DocScrutinizer05>
there's zilch benefit in *user* holding a hw-implemented enforced signature private key unique to his device, since absolutely same can (and always could) get done with regular user permissions and passwords (except maybe for coldflashing scenario which is sort of special and needs special consideration anyway). And user _not_ holding all keys but manufacturer keeping a single key for themselves is start of doom, no matter what
<DocScrutinizer05>
policies they promise
<DocScrutinizer05>
for security against bootloader exploits there's only one solution: do not allow coldflashing at all
<DocScrutinizer05>
flash a permissive bootloader that supports own replacement by user, then blowfuse-disable coldflashing
<DocScrutinizer05>
when user bricks his device then ... too bad
<DocScrutinizer05>
that's the price of absolute security
<wpwrak>
there is no absolute security :)
<DocScrutinizer05>
meh
jwhitmore_ has joined #qi-hardware
<DocScrutinizer05>
the better approach however, for mediocre security needs: for coldflashing you need to completely disassemble the device (add seals to the screws to make it even harder to do that unnoticed) and attach the device to a very "special" not very common fixture to do JTAG flashing or somesuch. Make sure the process takes ages
<wpwrak>
and for most users, having a device in such a state would make them a lot more vulnerable than having a pre-installed last line of defense
<DocScrutinizer05>
aha. Please elaborate
<DocScrutinizer05>
I guess Anelok can't even comply with the "coldflashing is impossible (without according signature key, if you insist)" requirement
<wpwrak>
the unalterable boot loader can implement an interface and mechanisms customers can actually use. forcing them to find an expert or forcing them to follow a list of arcane instructions does not empower them. to the contrary, it makes them more vulnerable.
<DocScrutinizer05>
sorry, this is lacking reference to what I said, in my book
<wpwrak>
(alas, still WIP. need to finish it some day.)
jwhitmore_ has quit [Ping timeout: 255 seconds]
<wpwrak>
tl;dr: you can lock the chip such that there is no known (to me) way to alter its content without the permission of the "boot loader"
<DocScrutinizer05>
well, then what is it you want to lock in there?
<wpwrak>
however, i control what that bootloader permits and what not :)
<DocScrutinizer05>
a bootloader that has a key you know of? then the concept is fubar. A key that only the user knows since he needs to set it? I don't see how to implement that
<wpwrak>
the boot loader has a list of public keys of authorized firmware suppliers. i (well, anelok ltd) would be one
<DocScrutinizer05>
OUCH!
<wpwrak>
and by default it may be the only one
<DocScrutinizer05>
double-OUCH
<wpwrak>
now, the boot loader will allow users to authorize other public keys, i.e., add them to the list. or delete them.
<DocScrutinizer05>
bus-factor: infinite
<DocScrutinizer05>
you're implementing Aegis
<wpwrak>
naw, very low: anelok ltd gets nuked, someone else can take over. all they need to do is convince users to trust them.
<DocScrutinizer05>
bwahaha, they need your secret unique key
<wpwrak>
again, the boot loader will allow users to authorize other public keys, i.e., add them to the list. or delete them.
<DocScrutinizer05>
how the heck you gonna do that?
<DocScrutinizer05>
how will you make sure the attacker evil maiden doesn't pretend to be he legit user?
<wpwrak>
details to be defined. but probably something along these lines: insert memory card with signed binary, reboot, boot loader detects what is there, asks whether to proceed, requests PIN if affirmative, displays another warning (since we're adding a key), maybe ask for the PIN again, then add the key and proceed
<DocScrutinizer05>
by shipping the master password for the device? well, every linux live distro does the same
<DocScrutinizer05>
where from is the root-PIN in that scenario, the initial PIN
<DocScrutinizer05>
the one PIN to rule them all
<wpwrak>
DocScrutinizer05: you enter it when you activate the device. that activation would be an irreversible process.
<DocScrutinizer05>
isn't it just the root password of classical linux user permissions/accounts handling that you need to provide to user since you've defined it at system-build time?
<wpwrak>
so the evil maid can destroy your brand-new anelok, but once you have activated it, she's powerless
<DocScrutinizer05>
((you enter it when you activate the device)) then your PubKey approach is more or less unneeded
<wpwrak>
you need the pubkey(s) to validate signed binaries.
<DocScrutinizer05>
it's basically just a backdoor account you coded in for yourself
<wpwrak>
these binaries can't bypass the boot loader
<wpwrak>
larsc: looks interesting, thanks !
<DocScrutinizer05>
then validation of those binaries is actuaölly in userland, as I requested
<wpwrak>
the "userland" concept doesn't quite apply here :) it's boot loader firmware vs. application firmware
<DocScrutinizer05>
aiui you need that signature on your binaries just to rise another warning requester when it doesn't exist
<DocScrutinizer05>
which pretty much flaws the concept - which is fine with me
<DocScrutinizer05>
either user can override such signature with a PIN they defined by themselves. Or you only can use signed binaries then the device is fubar
<wpwrak>
it's the former: the user can choose what to permit. well, in the general case. if someone wants a more or less restrictive boot loader (or none at all), that can be done :)
<DocScrutinizer05>
then the device has no scenario that would allow depriving user from 100% control, so it's a moot case for me and my concerns
<wpwrak>
depends on what you define as "100% control". but yes, anelok basically gives you as much control as you're willing to handle.
<DocScrutinizer05>
of course you'll sign your firmware releases with your private key, like everybody does with PGP to any arbitrary mail they send. And of yourse you're free to implement your pubkey into the device and use it to verify your firmware's authenticity, but it's up to the user if they want to make use of all that
<wpwrak>
of course, in some cases, you also need to order a test / programming fixture :) (for what you'd call JTAG)
<wpwrak>
users could also de-authorize my key, yes. probably after acknowledging a few more stern warnings, though :)
jwhitmore_ has joined #qi-hardware
wolfspraul has quit [Quit: leaving]
jwhitmore_ has quit [Ping timeout: 264 seconds]
<DocScrutinizer05>
http://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX%3A32014L0053&from=EN (EU Richtlinie Funkanlagen) >>Artikel 3 Grundlegende Anforderungen || (1) Bei Funkanlagen muss durch ihr Baumuster Folgendes gewährleistet sein [...] i) Sie unterstützen bestimmte Funktionen, mit denen sichergestellt werden soll, dass nur solche Software geladen werden kann, für die die Konformität ihrer Kombination mit der Funkanlage
<DocScrutinizer05>
nachgewiesen wurde.<<
<DocScrutinizer05>
this needs some refinement *urgently*, just like RYF of FSF it fails to distinguish between the complete system and a peripheral subsystem that happens to be a transceiver
<DocScrutinizer05>
for the modem as well as BT or WLAN it is in the responsibility of the subsystem to ensure that they operate within approved specifications. The manufacturer of a complete system is customer of the manufacturers of such subsystems and can't deal with regulatory requirements those subsystems may have, beyond the fact that they need to be type approved at the time of component selection resp design and approval of the complete system
<DocScrutinizer05>
heck we don't even know if the firmware blob we need to load to wl1273 WLAN chipset is protected by signature or not
<DocScrutinizer05>
and honestly how could we care?
<DocScrutinizer05>
for SDR on the other hand, situation is more nasty
<DocScrutinizer05>
and yes, probably stuff like cccamp Rad1o badge was already illegal to operate during this year's cccamp. And it would see quite some problems to get a CE approval ;-P right now as wel as next year when the above Richtlinie takes effect
<DocScrutinizer05>
otoh as long as the hardware imposes certain operational parameter limits, there's no need at all to worry about firmware needed to ensure the same parameter compliance
<DocScrutinizer05>
actually as long as "the software to load" has no impact on how the transmitter works (as is the case for Linux on a complete system of which a WLAN module is a subsystem), it's easy to prove on a logical level that the software is not covered by the above regulations
<DocScrutinizer05>
for the WLAN module itself only the manufacturer of such module can provide sufficient info to prove that the regulations are met
<DocScrutinizer05>
even while maybe the linux hosts a firmware blob to upload to the WLAN module RAM, it's not the linux system's responsibility to implement any security features regarding that firmware blob - unless the WLAN module manufacturer explicitly mandates for such measures being taken