| 00:00.18 | *** join/#neo900 atk (Arch-TK@ircpuzzles/staff/Arch-TK) |
| 02:05.12 | *** join/#neo900 chomwitt (~chomwitt@2a02:587:dc0e:3700:9c8b:49c7:cd17:5752) |
| 03:10.27 | *** join/#neo900 chomwitt (~chomwitt@2a02:587:dc0e:3700:9c8b:49c7:cd17:5752) |
| 03:21.46 | *** join/#neo900 metacollin (~metacolli@neo900/coreteam/metacollin) |
| 03:21.46 | *** mode/#neo900 [+v metacollin] by ChanServ |
| 03:29.55 | *** join/#neo900 knttl (~knttl@dyndsl-091-096-183-121.ewe-ip-backbone.de) |
| 03:30.18 | *** join/#neo900 Kabouik_ (~kabouik@32.232.202.84.customer.cdi.no) |
| 03:47.26 | *** join/#neo900 _xv33 (~xrvx_33@ip72-201-108-236.ph.ph.cox.net) |
| 03:58.43 | *** join/#neo900 ArturSha1 (~artur-sha@195.114.247.218) |
| 04:10.06 | Oksana | Is this kind of attack relevant for N900 or Neo900? https://iss.oy.ne.ro/Shattered <-- "chip-in-the-middle" scenario |
| 05:04.43 | sn0wmonster | iirc it's why Apple stopped using the headphone jack |
| 05:05.06 | sn0wmonster | (in addition to the added ability to make money closing the connectivity off to only their own wireless products at will) |
| 05:05.31 | sn0wmonster | might be wrong about that though, haven't looked it up in a while |
| 05:11.35 | tramtrist | people still mad about that? |
| 05:18.34 | Oksana | Nay, not headphone jack. |
| 05:19.02 | Oksana | Rather, a malicious chip inside display assembly. Two different attacks are described. |
| 05:19.42 | Oksana | One: touches being mis-reported, aka touch-screen getting a mind of its own, instead of reporting finger-touches properly. |
| 05:20.07 | Oksana | Two: buffer overflow allowing malicious code to gain control over more of the phone's hardware. |
| 05:21.33 | Oksana | While manufacturer may check the assembly before adding it into phone... After the phone is shipped to customer, customer may easily find display shattered, and replace it, with whatever spare part is available. |
| 05:29.43 | tramtrist | ha |
| 06:05.12 | *** join/#neo900 _cris (~cris@unaffiliated/cris/x-6073059) |
| 06:28.11 | *** join/#neo900 err0r3o3_ (~err0r3o3@91-114-175-248.adsl.highway.telekom.at) |
| 06:30.10 | *** join/#neo900 Pali (~pali@Maemo/community/contributor/Pali) |
| 06:31.49 | *** join/#neo900 err0r3o3_ (~err0r3o3@91-114-175-248.adsl.highway.telekom.at) |
| 07:35.41 | Joerg-Neo900 | Oksana: such attacks are always possible, they can place a eavesdropping devuce into your underwear. However such attack is very sophisticated for absolutely no obvious benefit from additional complexity |
| 07:40.24 | tramtrist | haha |
| 08:01.37 | Joerg-Neo900 | but simulating touch events is particularly tricky on Neo900 since the digitizer is passive |
| 08:03.05 | Joerg-Neo900 | the software attacks are what you get from poorly written software. Luckily on Neo900 there won't be any software you couldn't audit, unless you deliberately decide to install it |
| 08:16.21 | *** join/#neo900 jonsger (~Thunderbi@HSI-KBW-095-208-248-183.hsi5.kabel-badenwuerttemberg.de) |
| 08:30.59 | Joerg-Neo900 | fake touchscreen events also gives inspiration to thoughts about device lock code concepts. Obviously using a PIN on a fixed shape numeric keypad is completely wrong approach, the stories from fictional movies are legion how to trick those from thermal scan, vidoe of you entering it, fingerprints or other stains on HID and so on. probably a combination of "shake the device" gesture and tapping certain randomly *moving* targets on lockscreen is |
| 08:31.00 | Joerg-Neo900 | the way to go |
| 08:34.42 | Joerg-Neo900 | reCapchas are close but suffer a weakness form limited number of predefined riddle images on embedded |
| 08:37.01 | Joerg-Neo900 | when you make a keypad from 'flying numbers', you even can use PIN entry and it's relatively safe |
| 08:43.52 | sixwheeledbeast | when you say flying numbers I assume you mean numbers that are in different positions each time you hit a PIN entry screen? |
| 08:44.39 | Joerg-Neo900 | yes |
| 08:45.12 | Joerg-Neo900 | though it would be even better they moved during entry too |
| 08:46.45 | *** join/#neo900 Kabouik (~kabouik@129.242.224.17) |
| 08:48.00 | Joerg-Neo900 | point-in-time input events are *very* hard to replay later on, no matter what channel you use for spying, as long as spies don't have the actual visual feedback nor the original movie sequence |
| 08:49.37 | Joerg-Neo900 | think of a whhel of fortune type display and you simply shake device slightly when your next digit is "in the slot". Add to that a slight random jitter of the spinning speed of wheel |
| 08:50.47 | *** join/#neo900 deafboy (quasselcor@cicolina.org) |
| 08:52.18 | *** join/#neo900 illwieckz (~illwieckz@unvanquished/developer/illwieckz) |
| 08:53.33 | Joerg-Neo900 | you don't want same display for digits on a keypad even when you use one time random (static) digit positions in the pad. Since from brightness modulations it's still easy to determine which digit your finger pressed, no matter at which position it was, when somebody would for example take a video of you entering the code |
| 08:54.11 | sn0wmonster | > they can place a eavesdropping devuce into your underwear |
| 08:54.12 | sn0wmonster | lol |
| 08:55.04 | Joerg-Neo900 | your finger prssing a bright 8 on black background looks different from your finger pressing a ".", even when somebody only watches the light reflections in your face |
| 08:56.51 | Joerg-Neo900 | back in times of CRT TVs it was even possible to recover the actual display content aka picture from just watching the brightness / shine of the TV on your curtains |
| 08:57.35 | Joerg-Neo900 | the method been based on the idea that a CRT only 'draws' one pixel at a time |
| 09:06.15 | Joerg-Neo900 | so by simply pointing a very basic brightness sensor at your curtains, attacker can recover the (CVBS) Video signal instantly, with cheap hardware |
| 09:09.52 | Joerg-Neo900 | a good lockscreen would be for example a video of a ice hockey game where you touch then players with the right tricot number to imput your pin |
| 09:11.07 | Joerg-Neo900 | only downside: attacker might find dame vidoe and then exploit that info to determine where and when you touched |
| 09:11.16 | Joerg-Neo900 | s/dame/same/ |
| 09:12.02 | Joerg-Neo900 | so maybe rather make that a socker video game that has sufficient random in it to be completely safe from replay/prediction |
| 09:27.09 | Joerg-Neo900 | another probably safe concept: use a dial lock like on a steel vault. When lockscreen opens that dial is in a random postition, you use Vol+/- keys to spin it into correct position for first number. Then e.g press cam trigger or gipe devide t tap, to enter first number and make dial spin randomly again to a new random posution. Enter 2nd and 3rd number same way |
| 09:28.08 | Joerg-Neo900 | s/gipe/give/ |
| 09:28.36 | Joerg-Neo900 | ohm my, "give device a tap"* |
| 09:30.33 | Joerg-Neo900 | of yourse you also could spin the dial with whatever gesture on touchscreen, as long as it's sufficiently "analog", in that dial spin has acceleration etc |
| 09:30.51 | Joerg-Neo900 | needs more coffee, can't type |
| 09:33.25 | Joerg-Neo900 | actually the date&time input dialog on maemo's welcome screen is an excellent PIN entry method, however clumsy it is for the originally intended purpose. That clumsiness makes it ideal for PIN entry |
| 09:33.43 | Joerg-Neo900 | ;-)) |
| 09:34.14 | Joerg-Neo900 | what could be less suspicious than that notorious Date&Time entry dialog? ;-> |
| 09:36.22 | sixwheeledbeast | This is type of thing is used in the higher end of access control system. A button is pressed to light a decimal 7 seg grid of buttons randomly generated. Obviously the code is the same per user but the pattern is different each time. |
| 09:37.43 | *** join/#neo900 illwieckz (~illwieckz@unvanquished/developer/illwieckz) |
| 09:38.47 | Joerg-Neo900 | and would even suggest itself to dynamic PIN: set day of month to "$today - 6" (with wrap around to previous month, set the rest to the year and month of a date you can remember. Set hour and minute to a PIN you picked randomly |
| 09:38.51 | sixwheeledbeast | It's used for higher end but pretty secure by design. Especially in combination with a POTD (pin of the day) for example. |
| 09:43.05 | Joerg-Neo900 | yes, any sort of POTD is a good part of secure AUTH, ideally algorithmically derived from other environmental data like time of day, Date, or some data displayed on the HID |
| 09:43.43 | sixwheeledbeast | Low to medium risk is mostly prox now (RFID), this provides quick access but easily cloned. A pin is still preferred for higher security even over bio-metrics which have there issues. |
| 09:44.22 | Joerg-Neo900 | biometric is shite, never *really* works |
| 09:44.55 | Joerg-Neo900 | too easy to fake, easily gets confiused and then has false negatives too |
| 09:45.51 | sixwheeledbeast | yep, it's used mainly in clocking systems to avoid double clocking but it's rarely used for security. 10 years ago the industry said it was the future :rollseyes: |
| 09:46.11 | Joerg-Neo900 | stuff like fingerprint sensors or face / voice / iris recognition is really only for low security convenience stuff |
| 09:47.08 | Joerg-Neo900 | all way too fragile and way too simple to fake |
| 09:47.30 | sixwheeledbeast | All been replaced with prox tags as the hardware is more stable. |
| 09:47.43 | Joerg-Neo900 | :mod: but easily lost |
| 09:47.51 | Joerg-Neo900 | or stoledn, or even cloned |
| 09:47.54 | sixwheeledbeast | and copied |
| 09:48.39 | Joerg-Neo900 | runs for coffee, while mumbling excuses for terrible typing |
| 09:48.39 | sixwheeledbeast | :nod: but again it low to medium risk. Security is relative to risk due to costs. |
| 09:49.06 | Joerg-Neo900 | yes, obviously |
| 09:50.11 | Joerg-Neo900 | that's why I said for Neo900 such hidden rogue chip atacks are highly improbable since they cost way too much for a result you can achieve more cheap and easy |
| 09:52.29 | Joerg-Neo900 | it's like running away from a lion - you're fast enough when you're faster than the slowest person of the group |
| 09:52.32 | Joerg-Neo900 | ;-) |
| 09:53.43 | Joerg-Neo900 | you hardly can be faster than the lion |
| 09:55.08 | Joerg-Neo900 | Neo900 concept somewhat resembles lizards: when under attack you could drop a fake bait to stop and distract the attacker from attacking you |
| 09:56.45 | Joerg-Neo900 | for that you need to detect an attack, to start with. It's not like we try to harden like a turtle so atacks would never hurt us. Since that's probably futile given the capabilities of the attacker |
| 10:00.43 | Joerg-Neo900 | see wpwrak's talk quote: "...and you decide to turn right instead and head to the supermarket, buying stuff and then return home" |
| 10:02.00 | Joerg-Neo900 | so for lockscreen I strongly suggest to not reject unlocking device when wrong PIN got enetered, but instead unlock a fake device with fake bogus data booty for the spy |
| 10:03.47 | sn0wmonster | deterministic VMs |
| 10:03.48 | sn0wmonster | lol |
| 10:04.21 | sn0wmonster | that was one thing i liked about Truecrypt/Veracrypt, and continue to like about BIP39 bitcoin wallets |
| 10:04.38 | sn0wmonster | you enter password1 and get a different fully functional wallet than if you enter password2 |
| 10:04.41 | Joerg-Neo900 | yeah, the plausible deniability |
| 10:04.43 | sn0wmonster | ultimate deniability |
| 10:04.46 | sn0wmonster | ^ |
| 10:05.44 | Joerg-Neo900 | folks, I only try to provide the hw and the concepts, you need to do the implementation :-) |
| 10:06.25 | *** join/#neo900 chainsawbike (~chainsawb@unaffiliated/chainsawbike) |
| 10:06.59 | Joerg-Neo900 | which makes a lot of sense, in a context of security. You shouldn't trust anything software you didn't build yourself. For the hw you're free to check the schematics against the actual physical PCB |
| 10:08.02 | *** join/#neo900 illwieckz (~illwieckz@unvanquished/developer/illwieckz) |
| 10:17.14 | Joerg-Neo900 | ((unlock a fake device)) that's also a good way to make the attacker keep the device active, to allow complete erasure of the protected content in background |
| 10:18.13 | sixwheeledbeast | Bit difficult to do that type of thing with physical electronic security... lol |
| 10:18.16 | Joerg-Neo900 | similar rationale applies when the average junkie steals your device. Fake power-off so you can still track |
| 10:18.37 | sixwheeledbeast | imagines a "go straight to jail don't pass go" door opening |
| 10:19.05 | Joerg-Neo900 | hm? |
| 10:19.23 | sn0wmonster | Monopoly |
| 10:19.31 | Joerg-Neo900 | fake system for plausible deniability is not a hardware thing |
| 10:20.12 | Joerg-Neo900 | it's also not forbidden afaik |
| 10:21.29 | Joerg-Neo900 | of course the real tough TLA guys will not even *try* to unlock your device the usual way. They go to disassemble and forensically analyze it right away |
| 10:22.35 | Joerg-Neo900 | again a question of cost/expense vs benefit ratio |
| 10:27.18 | Joerg-Neo900 | when you don't agree on US customs copying the complete content of your smartphone, any low level plausible deniability solution totally suffices to stop them from getting your contacts and chats |
| 10:30.36 | Joerg-Neo900 | the room cleaner attack used to install a tracker software to your device into the fake system will also miss it's aim |
| 10:35.30 | Joerg-Neo900 | you can either try to harden/lock your device to forbid the rogue neighbor to install such tracker, until finally you lose the daily battle one day and they install the tracker nevertheless. Or you *allow* then to succeed instaling tracker right away, just not to your real system but to a fake system where it is 'in quarantine' and you instantly get to know about the failed attack |
| 10:35.58 | *** join/#neo900 Kabouik (~kabouik@129.242.224.17) |
| 10:37.19 | sn0wmonster | which is why #OPSEC is not always about protecting against, but counter-surveillance and honeypots |
| 10:37.31 | sn0wmonster | key point being isolation |
| 10:37.43 | Joerg-Neo900 | yep |
| 10:38.31 | *** join/#neo900 illwieckz (~illwieckz@unvanquished/developer/illwieckz) |
| 10:40.44 | Joerg-Neo900 | on hw level that's why we isolate the considered-rogue modem and tightly monitor it for any unusual behavior |
| 10:41.26 | Joerg-Neo900 | no auditing of modem radio stack firmware could actually win the protection battle for all times |
| 10:42.25 | *** join/#neo900 jkepler (~Thunderbi@gateway/vpn/privateinternetaccess/jkepler) |
| 10:48.46 | Joerg-Neo900 | we also make sure you can't enter flashing mode on system boot time (like on N900) unless you have removed batery lid. So no rogue charger port at airport or pub could compromise your device by reflashing it without you even noticing |
| 10:49.50 | Joerg-Neo900 | reflasjing or simply using rescueOS to read out whatever the attacker is interested in |
| 10:52.12 | Joerg-Neo900 | for the paranoid users there's a trace to cut, to completely disallow flashing mode unless xloader allows it, which is a thing user may vontrol via software (e.g. by asking for PIN to allow flashing) |
| 11:06.11 | *** join/#neo900 illwieckz (~illwieckz@unvanquished/developer/illwieckz) |
| 11:09.11 | sn0wmonster | https://public-inbox.org/git/xmqqh8xf482j.fsf@gitster.mtv.corp.google.com/T/#u |
| 11:12.26 | Joerg-Neo900 | LOL |
| 11:12.44 | Joerg-Neo900 | nice one |
| 11:14.10 | Joerg-Neo900 | sn0wmonster: many thanks! :-) |
| 11:14.38 | Joerg-Neo900 | checks for available git updates |
| 11:19.09 | *** join/#neo900 cc___ (~ac@2001:910:113f:1:6a05:caff:fe1c:1627) |
| 11:19.18 | Joerg-Neo900 | ugh 11 days old |
| 11:43.40 | *** join/#neo900 _cris (~cris@82.137.15.167) |
| 11:47.41 | *** join/#neo900 jonsger (~Thunderbi@HSI-KBW-095-208-248-183.hsi5.kabel-badenwuerttemberg.de) |
| 12:22.15 | *** join/#neo900 Kabouik (~kabouik@129.242.224.17) |
| 15:13.20 | *** join/#neo900 freemangordon (~ivo@46.249.74.23) |
| 15:32.08 | *** join/#neo900 Pali (~pali@Maemo/community/contributor/Pali) |
| 15:56.59 | *** join/#neo900 Kabouik (~kabouik@32.232.202.84.customer.cdi.no) |
| 16:11.21 | *** join/#neo900 ArturShaik (~artur-sha@212.97.27.139) |
| 17:00.20 | *** join/#neo900 Kabouik (~kabouik@32.232.202.84.customer.cdi.no) |
| 17:02.25 | *** join/#neo900 Kabouik (~kabouik@32.232.202.84.customer.cdi.no) |
| 17:03.00 | *** join/#neo900 Kabouik (~kabouik@32.232.202.84.customer.cdi.no) |
| 17:17.56 | *** join/#neo900 ArturSha1 (~artur-sha@195.114.248.72) |
| 18:05.29 | *** join/#neo900 chainsawbike (~chainsawb@unaffiliated/chainsawbike) |
| 18:23.36 | *** join/#neo900 Kabouik_ (~kabouik@ks3100825.kimsufi.com) |
| 18:28.41 | *** join/#neo900 vlitzer (~vlitzer@199.33.128.160) |
| 18:33.54 | *** join/#neo900 arnaudj (~Thunderbi@85-171-19-190.rev.numericable.fr) |
| 18:57.17 | *** join/#neo900 arnaudj (~Thunderbi@85-171-19-190.rev.numericable.fr) |
| 19:09.07 | *** join/#neo900 arnaudj (~Thunderbi@85-171-19-190.rev.numericable.fr) |
| 19:14.12 | *** join/#neo900 arnaudj1 (~Thunderbi@85-171-19-190.rev.numericable.fr) |
| 19:18.55 | *** join/#neo900 Kabouik (~kabouik@ks3100825.kimsufi.com) |
| 19:53.55 | *** join/#neo900 chomwitt (~chomwitt@2a02:587:dc0e:3700:9c8b:49c7:cd17:5752) |
| 19:54.51 | *** join/#neo900 pagurus (~user@p4FDC3828.dip0.t-ipconnect.de) |
| 19:55.48 | *** join/#neo900 Kabouik (~kabouik@ks3100825.kimsufi.com) |
| 20:01.04 | *** join/#neo900 Kabouik_ (~kabouik@32.232.202.84.customer.cdi.no) |
| 20:20.14 | *** join/#neo900 vlitzer (~vlitzer@199.33.128.160) |
| 22:25.43 | *** join/#neo900 _cris (~cris@82.137.15.167) |
| 22:45.28 | *** join/#neo900 Kabouik (~kabouik@32.232.202.84.customer.cdi.no) |
| 22:47.05 | *** join/#neo900 Kabouik_ (~kabouik@169.ip-37-187-176.eu) |