#qi-hardware IRC log for Thursday, 2015-09-03

DocScrutinizer05does anybody recall / know about the USB 30V thing?00:16
whitequarkI do02:58
DocScrutinizer05could you share a pointer?03:29
DocScrutinizer05I can't find it anymore03:30
DocScrutinizer05unless it's -- (20V, not 30): https://de.wikipedia.org/wiki/Universal_Serial_Bus#USB_3.1_mit_Typ-C-Steckverbindung03:31
whitequark20V@5A=100W, so yes04:31
wpwrakthis reads like a declaration of war: http://www.heise.de/netze/meldung/Funkregulierung-Angriff-auf-alternative-Software-2803189.html12:50
DocScrutinizer05is *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 17:22
DocScrutinizer05and it seems there are not even a good selection of chipsets that would allow building products that could comply17:23
DocScrutinizer05basically so far the consensus seems to be it basically forbids linux on laptops - up to you to imagine similar usecases where it kicks in17:30
wpwrakreading 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.17:43
wpwraki.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.17:44
larscany modification that allows the end-user to potentially use the devices in a mode or configuration it was not certified for must be prevented17:45
wpwrakwhich document are you referring to ?17:46
larscthat's the common interpretation of the regulations17:48
wpwraki'm more looking for explicit wording17:54
larscthe fcc servers with the documents are down18:03
wpwrakso it seems18:03
larscthis is one of the requirements18:04
larsc"What prevents third parties from loading non-US versions of the18:04
larscsoftware/firmware on the device? Describe in detail how the device is18:04
larscprotected from flashing and the installation of third-party firmware such as18:04
larscDD-WRT." 18:04
DocScrutinizer05which is the complete fsckup18:12
DocScrutinizer05it means mandatory tivoization in all devices18:12
wpwrakyou 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.),18:13
DocScrutinizer05you won't get away with that and it already implies you implement tivoization18:14
wpwrak3) 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)18:14
wpwraks/didn't as/didn't ask/18:15
DocScrutinizer05anelok for example is not legal according to those rules18:16
DocScrutinizer05users any time can create their own "3rd party sfirmware" and operate the device outside the approved specs18:16
wpwrakDocScrutinizer05: 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.18:16
DocScrutinizer05no, I generally reject signed binaries18:17
DocScrutinizer05no matter which key infra you install. It can and *will* get abused18:18
DocScrutinizer05and it makes developing stuff a misery for everyone18:18
DocScrutinizer05been there, seen that, Nokia N9 Aegis18:19
DocScrutinizer05signed binaries are *never* in the interest of end users18:19
DocScrutinizer05unless it's a repository signature for integrity and authenticity checks18:20
wpwrakheh, i was just about to point this out :)18:20
DocScrutinizer05even then such signature needs to get handled in userland, not on kernel or even bootloader level18:21
infobothttp://www.developer.nokia.com/Community/Wiki/Harmattan:Developer_Library/Developing_for_Harmattan/Harmattan_security/Security_guide , or "The purpose of this framework is: ... to make sure that the platform meets the requirements set by third party software that requires a safe execution environment.", or http://en.wikipedia.org/wiki/Trusted_Computing#Criticism, or  http://en.qi-hardware.com/w/images/1/10/ME_382_LockedUpTechnology2.gif18:22
wpwraki guess you won't like anelok then ;-)18:22
DocScrutinizer05when it _allows_ a scenario where user doesn't have 100% control over the device, then I for sure won't like it18:23
wpwraksuch 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.18:28
DocScrutinizer05there'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 18:28
DocScrutinizer05policies they promise18:29
DocScrutinizer05for security against bootloader exploits there's only one solution: do not allow coldflashing at all18:31
DocScrutinizer05flash a permissive bootloader that supports own replacement by user, then blowfuse-disable coldflashing18:32
DocScrutinizer05when user bricks his device then ... too bad18:33
DocScrutinizer05that's the price of absolute security18:33
wpwrakthere is no absolute security :)18:33
DocScrutinizer05the 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 ages18:36
wpwrakand 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 defense18:36
DocScrutinizer05aha. Please elaborate18:37
DocScrutinizer05I guess Anelok can't even comply with the "coldflashing is impossible (without according signature key, if you insist)" requirement18:39
wpwrakthe 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.18:39
DocScrutinizer05sorry, this is lacking reference to what I said, in my book18:40
wpwrak(coldflash) see http://downloads.qi-hardware.com/people/werner/anelok/tmp/klsec-20141005.pdf18:40
wpwrak(alas, still WIP. need to finish it some day.)18:41
wpwraktl;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"18:42
DocScrutinizer05well, then what is it you want to lock in there?18:42
wpwrakhowever, i control what that bootloader permits and what not :)18:42
DocScrutinizer05a 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 that18:43
wpwrakthe boot loader has a list of public keys of authorized firmware suppliers. i (well, anelok ltd) would be one18:44
wpwrakand by default it may be the only one18:44
wpwraknow, the boot loader will allow users to authorize other public keys, i.e., add them to the list. or delete them.18:45
DocScrutinizer05bus-factor: infinite18:45
DocScrutinizer05you're implementing Aegis18:46
wpwraknaw, very low: anelok ltd gets nuked, someone else can take over. all they need to do is convince users to trust them.18:46
DocScrutinizer05bwahaha, they need your secret unique key18:46
wpwrakagain, the boot loader will allow users to authorize other public keys, i.e., add them to the list. or delete them.18:47
DocScrutinizer05how the heck you gonna do that?18:47
DocScrutinizer05how will you make sure the attacker evil maiden doesn't pretend to be he legit user?18:48
wpwrakdetails 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 proceed18:49
DocScrutinizer05by shipping the master password for the device? well, every linux live distro does the same18:49
larscwpwrak: have you seen http://lists.prplfoundation.org/cgi-bin/mailman/listinfo/fcc18:50
DocScrutinizer05where from is the root-PIN in that scenario, the initial PIN18:51
DocScrutinizer05the one PIN to rule them all18:52
wpwrakDocScrutinizer05: you enter it when you activate the device. that activation would be an irreversible process.18:53
DocScrutinizer05isn'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?18:53
wpwrakso the evil maid can destroy your brand-new anelok, but once you have activated it, she's powerless18:53
DocScrutinizer05((you enter it when you activate the device)) then your PubKey approach is more or less unneeded18:54
wpwrakyou need the pubkey(s) to validate signed binaries.18:55
DocScrutinizer05it's basically just a backdoor account you coded in for yourself18:55
wpwrakthese binaries can't bypass the boot loader18:55
wpwraklarsc: looks interesting, thanks !18:55
DocScrutinizer05then validation of those binaries is actuaölly in userland, as I requested18:56
wpwrakthe "userland" concept doesn't quite apply here :) it's boot loader firmware vs. application firmware18:58
DocScrutinizer05aiui you need that signature on your binaries just to rise another warning requester when it doesn't exist19:06
DocScrutinizer05which pretty much flaws the concept - which is fine with me19:08
DocScrutinizer05either user can override such signature with a PIN they defined by themselves. Or you only can use signed binaries then the device is fubar19:10
wpwrakit'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 :)19:11
DocScrutinizer05then the device has no scenario that would allow depriving user from 100% control, so it's a moot case for me and my concerns19:13
wpwrakdepends on what you define as "100% control". but yes, anelok basically gives you as much control as you're willing to handle.19:14
DocScrutinizer05of 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 that19:15
wpwrakof course, in some cases, you also need to order a test / programming fixture :) (for what you'd call JTAG)19:15
wpwrakusers could also de-authorize my key, yes. probably after acknowledging a few more stern warnings, though :)19:16
DocScrutinizer05http://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 21:29
DocScrutinizer05nachgewiesen wurde.<<21:29
DocScrutinizer05this 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 transceiver21:31
DocScrutinizer05for 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 system21:35
DocScrutinizer05heck we don't even know if the firmware blob we need to load to wl1273 WLAN chipset is protected by signature or not21:37
DocScrutinizer05and honestly how could we care?21:38
DocScrutinizer05for SDR on the other hand, situation is more nasty21:38
DocScrutinizer05and 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 effect21:40
DocScrutinizer05otoh 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 compliance21:42
DocScrutinizer05actually 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 regulations22:08
DocScrutinizer05for the WLAN module itself only the manufacturer of such module can provide sufficient info to prove that the regulations are met22:09
DocScrutinizer05even 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 taken22:12
--- Fri Sep 4 201500:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!