<Joerg-Neo900>
yes, there are a 1000 hardware silicon switches that enable microphone
<Joerg-Neo900>
caled transistors
<Pali>
I mean hw button/switch
<Joerg-Neo900>
this is hw :-o
<Pali>
something which is visible and can be verified by eye :-)
<Joerg-Neo900>
if you mean *mechanical* then no, this is an electronic device
<Pali>
yes, mechanical I mean
<Joerg-Neo900>
it's not operated by steam
<Joerg-Neo900>
why would anybody on earth want a mechanical switch?
<Pali>
basically software in device can be compromitted and report wrong data about state of modem/microphone
<Pali>
but mechanical switch is hard to vulnerable from software...
<Joerg-Neo900>
if you don't trust our ability to design a secure electronic solution and your ability to control that secure solution with your very own software code, why would you trust in a mechanical switch still operating in same electronic environment (and possibly implemented in an unsafe way) and your ability to conclude cirrect opeation of that mech switch from visual inspection?
<Joerg-Neo900>
and when linux in device gets compromised then you better cure that with a sledge hammer
<Pali>
as we know security vulnerables are in every software and program which will show status of modem or microhpone can be vulnerable too
<Joerg-Neo900>
there's ZILCH use in a switch then, you need to at very least remove battery and only re-insert it in an unechoic chamber the earliest, if ever again at all
<Pali>
attacker can replace that part of SW and I will just see "modem is disabled" and "microphone is turned off"
<Joerg-Neo900>
no
<Pali>
but it will not be truth and modem can be still enabled
<Joerg-Neo900>
that's BS
<Joerg-Neo900>
attavker can not "replace arbitrary parts of linux"
<Pali>
if he find vulnerability in kernel, then yes
<Joerg-Neo900>
then get a windows device!
<Pali>
what will help me?
<Joerg-Neo900>
where's tghe switch on your PC?
<Pali>
I'm saying that mechanical switch provides more security as software defined
<Joerg-Neo900>
you are a software developer and kernel maintainer and you ask for a SWITCH??
<Pali>
also on laptops used to be (and I still have!) one to turn off radio devices
<Xiaoman>
Plot twist: What if the attacker uses the speakers as a microphone?
<Joerg-Neo900>
Pali: sorry that's BS, you don't have a purely mechanical swirch neither for microphone nor for wireless on any laptop
<Xiaoman>
Pali: That only sends a signal, it doesn't actually physically remove the connections in print.
<Pali>
yes, it is some hw-sw based, at least after switching it bluetooth device disappear from usb usb
<Pali>
*usb bus
<Joerg-Neo900>
if we would intend to ship a SECUUURE device like you're asking for, we had to flash the complete OS to ROM
<Xiaoman>
Pali: What if the kernel reactivates the device, or simply ignore the signal?
<Pali>
Xiaoman: kernel does not process that signal
<Joerg-Neo900>
either you trust yourself to keep your linux clean or you better don't use a linux device. period
<Pali>
it just get information that bluetooth device was disconnected from usb bus
<Pali>
is it really hw based
<Xiaoman>
Pali: Something has to, if not *your* kernel, then what? Some BIOS maybe? Who controls the bios? Oh wait..
<Pali>
embedded controller
<atk>
I imagine anyone claiming to implement a hardware switch for these things doesn't actually implement it, I have a feeling routing audio to a button and back would be a pain in the ass interference wise.
<Joerg-Neo900>
BWAHAHA
<atk>
Same with an antenna
<Joerg-Neo900>
atk: absolutely
<Joerg-Neo900>
also a terrible botch for those wo can't do it in software
<atk>
The other option is to have a random switch on the middle of the PCB somewhere and even that will probably cause all sorts of issues with height.
<Xiaoman>
Pali: From a security perspective, what you want is not practically feasable, and probably not something you have ever, or will ever encounter.
<atk>
And then you'd have to unscrew your phone to switch it.
<Joerg-Neo900>
now when you don't trust your own admin skills, then you better steer clear of any such device by at least 500m
<atk>
At this point, you might as well just remove the battery.
<atk>
If your phone sw is compromised to the point where the states of these kill switches are misreported, GSM modem and mic are probably the least of your worries.
<Joerg-Neo900>
and such switch STILL could be bogus, you CANNOT check that visually
<Pali>
one thing is truting own skill another thing is prevention of security problems in application and know what to do if security vulnerability is found in any part of SW
<Xiaoman>
Why even have a phone turned ON, when modem/microphone is not physically connected? What possible purpose could the device hold then?
<atk>
yeah, someone could place a bridge under the switch and you would never know.
<Pali>
atk: yes, but that need physical access and modifiation
<Pali>
as I wrote that is not possible to do via software
<Joerg-Neo900>
Pali: nobody came up with any solution for that, other than tivoization and trusted computing, which simply moves the responsibility from you (user) to them (manufacturer)
<Xiaoman>
Pali: No, you cannot in any practical sense check it yourself.
<atk>
My point regarding mic and modem being the least of your worries still stands.
<Xiaoman>
Joerg-Neo900: Apropos CCC, are you attending with something this year?
<Joerg-Neo900>
no
<Xiaoman>
:(
<Joerg-Neo900>
sorry
<Joerg-Neo900>
health issues
<Xiaoman>
Aww
<Pali>
I'm saying that potential problem when *SW* will be compromised, mechanical switch can mitigate problems
<Xiaoman>
Pali: If the SW is compromised, then I assume that you won't use the device, hence why you want to disable hardware... Why not just... Turn it off and throw it away?
<Pali>
software based switch is usless after somebody will hack your software
<Xiaoman>
Why would you want a switch?
<Joerg-Neo900>
and I say that is moot since a device with compromised software is dangerous like a can of nitroglycerine anyway and you should instantly remove battery or microphone is prolly your least problem
<Xiaoman>
Let's start from the beginning: Why do you want a switch for either modem or microphone?
<Pali>
but sometimes it is hard to detect such attack
<Joerg-Neo900>
TZHEN WHAT?
<Xiaoman>
wut
<Pali>
Xiaoman: in case attacker get access to my device and replace sw which show status of modem
<Joerg-Neo900>
you at very least have a few LEDs you could check, in Neo900
<Xiaoman>
How will a hardware switch help you if you don't know you are compromised?
<atk>
if someone "hacked" your software you have bigger problems than antenna and microphone
<Pali>
in that case I get false information
<Joerg-Neo900>
atk: EXACTLY
<Xiaoman>
Pali: If a worthy advesary gains access to your equipement, then you cannot trust hardware of the device, which means you have to throw it away.
<Pali>
atk: I would have bigger problems if somebody start recording me
<Xiaoman>
Please step up your game.
<atk>
They would start recording you long before you noticed.
<Xiaoman>
You try to defend against irrelevant and unrealistic scenarios
<Joerg-Neo900>
they would also scoop all your data
<Pali>
if microphone is turned off by mechanical switch, then attacker cannot record me
<Joerg-Neo900>
haha, says who?
<Joerg-Neo900>
[2016-12-14 Wed 01:41:02] <Xiaoman> Plot twist: What if the attacker uses the speakers as a microphone?
<Pali>
if he just hack some userspace
<Xiaoman>
Pali: I'm not sure if you are trying to troll or literally talking about stuff you don't know right now.
<Joerg-Neo900>
or use barometer, or accelerometer
<Pali>
I'm trying to talk
<Pali>
no trolling
<Xiaoman>
Then stop talking and start learning about threat models and risk management.
<Xiaoman>
And then get some technical insight.
<Pali>
direct access to microphone data are more more dangerous as barometer or accelerometer
<Xiaoman>
Pali: Please follow my advice, for your own sake.
<Joerg-Neo900>
you cannpt defeat a threat by switching off microphone. That's like "did you place the coal into a steel bucket in that wooden house, to prevent a fire?"
<Pali>
if I do not use microphone it is turned off... if I do not use modem it is turned off too...
<Xiaoman>
wut
<Xiaoman>
I don't even
<Joerg-Neo900>
yes, same on Neo900
<atk>
Pali: they'll just record you when you switch it back on.
<Xiaoman>
Every phone works like that.
<Xiaoman>
Even my computer.
<Pali>
and I'm just saying that prevention to enable it via SW can mitigate problems when somebody get access to phone
<Xiaoman>
No.
<Pali>
atk: yes, but it is not immediately and I can detect such attack
<Joerg-Neo900>
again, in that case YOU GOT WAY BIGGER PROBLEMS
<atk>
How can you detect such an attack?
<atk>
How can you detect compromised software?
<atk>
Surely if someone can compromise it, they can work out how to hide it?
<Joerg-Neo900>
you need secure and rogue zones to shut down the rogue zones. If you consider complete device rogue, you HAVE TO switch off complete device
<Pali>
depends on attack... if he uses some security problem which is logged, then I can detect it later
<Joerg-Neo900>
aka "REMOVE BATTERY"
<atk>
only if, what if he uses your speaker as a microphone too?
<atk>
What if he doesn't use some security problem which is logged?
<Pali>
then it does not help me
<atk>
what if he alters the logs?
<Xiaoman>
Pali: I have a security related feature in mind for Neo900 that has the same security benefits as what you suggest, want to hear it?
<Joerg-Neo900>
cookie steel box?
<Joerg-Neo900>
or sledge hammer?
<atk>
The point is, this feature would only be helpful in a handful of situations, and more importantly if your software was compromised you would have much bigger problems. A more useful solution would be to add LEDs to key parts of the circuit to detect when the microphone or antenna is in use (not sure how difficult this is). This would actually allow you to verify software behaviour against hardware behaviour.
<atk>
And I'm pretty sure neo900 will have some fancy LEDs in key places (can't quite remember where)
<Joerg-Neo900>
>>add LEDs to key parts of the circuit to detect when the microphone or antenna is in use<< which is indeed what Neo900 HAS
<Xiaoman>
Oh well, heres goes anyway, Joerg-Neo900 get on implementing right away!: All Neo900 needs to be painted pink and have dildo stickers on them. This ensures that any attacker that is also afraid of touching dicks will abstain from doing malicious things that requires physical access.
<atk>
hahaha
<Xiaoman>
And can I get mine hand painted, I'm afraid that a mass production edition might desensitize certain people.
<Xiaoman>
Thanks.
<Joerg-Neo900>
Pali: bottom line: such a switch is mere snake oil from a security expert POV
<atk>
And would be a pain to correctly implement in a convenient place.
<Joerg-Neo900>
a concept invented by people who have literally no idea of electronics and of opsec
mzki has quit [Ping timeout: 250 seconds]
<Joerg-Neo900>
ooh yes, that too. impossible to implement in Neo900 and the N900 case we use
<atk>
(So anyone who DOES do it either runs coax to and from the switch or is at some point using a solution involving some transistors)
<Xiaoman>
The switch on my laptop is handy for telling my kernel to disable/enable wifi card though. No need to have it enabled if it is just going to use power.
<Joerg-Neo900>
well, pretty much impossible
<atk>
Xiaoman: yes, but how do you think that switch is implemented?
<Joerg-Neo900>
GPIO, clearly
<Xiaoman>
atk: Sends signal to coreboot which tells kernel to stop using it.
<Joerg-Neo900>
ack
<Xiaoman>
in hardware I have no idea
<atk>
to coreboot?
<Xiaoman>
<- Don't know shit about hardware or software.
<Xiaoman>
My BIOS thingy.
<Xiaoman>
Pretty sure that coreboot keeps hardware state and the kernel trusts it.
<atk>
Your BIOS is unlikely to run after the kernel finishes asking it questions and goes into protected mode.
<Pali>
so, ok, led consistency for mic
<Xiaoman>
Alrighty.
<Xiaoman>
Maybe I should read up on how it works
<Pali>
but still, I would like to know, what is wrong with dedicated mechanical switches?
<atk>
...
<Joerg-Neo900>
whenever somebody asks about mech switch in Neo900, we tell him "we got something even better: electronic switch under 100% user control, 3 independent hardware threat detectors PLUS a visual detector called LED"
<atk>
Well, we did explain that at least five times.
<Joerg-Neo900>
in this case simplicity is a virtue though
<Joerg-Neo900>
one on modem power, one on digital mic power
<atk>
Is there info on how they're going to be implemented? I imagine certain subsystems will receive power when they're in use and the LED just goes across from the power rail, through a resistor to ground?
<atk>
Ah, as I guessed.
<Joerg-Neo900>
yes, exactly
<Joerg-Neo900>
high efficiency LEDs which work form a fraction of 1mA already
<atk>
I imagine the resistor value will much higher than needed to conserve power and make the LED last longer? (But it sounds like they don't use much power to begin with)
<Joerg-Neo900>
energy conservation. every mA counts
<atk>
Well anyway, interesting information but I have to go to sleep.
<atk>
Isn't it 2 am over there?
<Joerg-Neo900>
iir they could cope with 10mA and that's what you could teak the series R for, on modem LED. For mic power it's a tad more limited since that's powered from a pretty weak power source
<Joerg-Neo900>
yes
<Joerg-Neo900>
I just woke up
<Joerg-Neo900>
health, toldya
<Joerg-Neo900>
Pali: with LEDs you will BOTICE any threat instantly, instead of hoping to "keep the door closed so it stays outside"
<Joerg-Neo900>
Notice even
<Pali>
understood
<Pali>
leds can be disabled?
<Joerg-Neo900>
and that's the security concept of whole Neo900: it's pointless to try defeat threats, you're way better off when you NOTICE them right away
<Joerg-Neo900>
no
<Joerg-Neo900>
you can remove them, or paint them black ;-)
<Pali>
ok, so attacker cannot turn leds and after that start recording, right?
<Joerg-Neo900>
so again no defense against physical attack ;-P
<Joerg-Neo900>
no way
<Pali>
ok
<Pali>
sorry for a noise then... but lot of times my rule is to turn (even mechanically) off what is not used
<Joerg-Neo900>
:-)
<Joerg-Neo900>
much apprecitaed, no kidding. We need that sort of feedback
<Joerg-Neo900>
to both check our own design and to spread the word
<Joerg-Neo900>
and we benefitted form that already in that we noticed the LEDs should go to BD
<Joerg-Neo900>
from*
<Pali>
just to note that mechanical switch on my laptop turn bluetooth totally off; even kernel does not see it and cannot use it
<Joerg-Neo900>
wpwrak: please add a indicator LED to modem-power and to mic-power
<Pali>
it is not independent of main processor & kernel
<Pali>
is there some more detailed information about ECI?
<Joerg-Neo900>
ECI is a single wire bidir serial protocol in the lower kBaud range
<Pali>
at least I was not able to find anything else...
goiken_ has quit [Ping timeout: 258 seconds]
<Joerg-Neo900>
no, not much, except the (e.g. N9) linux codes
<Joerg-Neo900>
source
<Pali>
there is some x86 intel-mid source code too
<Joerg-Neo900>
those explain the data structures and a tad of the protocil
<Pali>
but just API for some eci controller, not protocol
goiken_ has joined #neo900
<Joerg-Neo900>
the protocol is in sources, the PHY isn't
<Joerg-Neo900>
PHY and layer one
<Joerg-Neo900>
the commands, even incl some timing, and data structures though are there
<Pali>
and do we know that n900 definitelly cannot support it?
<Joerg-Neo900>
I think N900 CAN definitely support it
<Joerg-Neo900>
alas we need to bitbang serial since we got no dedicated UART
<Pali>
hm... but documentation for those twl4030 blocks are missings
<Joerg-Neo900>
which is not as bad as it sounds, given we have a a hw IRQ for inbound data, and a rather low baudrate
<Joerg-Neo900>
there are two comparators for inbound data that are directly to IRQ-enabled GPIO
<Joerg-Neo900>
and there's the rather fast analog mux switch for TV/mic for outbound data bitbang
<Joerg-Neo900>
in addition you got ECI-ADC in
<Joerg-Neo900>
which also could possibly act as data-out too, but I wouldn't follow that idea
<Pali>
how is working that n900 headset with one button?
<Pali>
it is not eci?
<Joerg-Neo900>
and absolutely worst case we could sample data-in via the audio ADC
<Pali>
I was thinking if it could be possible to implement eci in software with some sound card...
<Joerg-Neo900>
it is a very low complexity niche case of ECI, yes
<Joerg-Neo900>
ECI inbound data is basically doing UART serial by very very fast "push the button"
<Joerg-Neo900>
to do simple 8N1 or whatever serial
<Joerg-Neo900>
or maybe PWM with short and long pulses for 0 and 1
<Joerg-Neo900>
outbound is basically absolutely same, just the "button" to short the single line to GND is inside N900 in that case
knttl has quit [Ping timeout: 256 seconds]
<Joerg-Neo900>
N900 starts ECI session by sending a "read out parameters" command to the headset, and then reads a iirc 256bytes data from a NV-storage in headset
<Joerg-Neo900>
for any multimedia button press on HS, the HS "pulses the button" to send a few bytres serial data to the N900
varu|zZz has joined #neo900
<Joerg-Neo900>
baudrate absolutely not higher 10kBaud
<Joerg-Neo900>
100
<Joerg-Neo900>
prolly in the <1000baud range
knttl has joined #neo900
<Joerg-Neo900>
eventually I'll provide an analysis, I got the tools and just need a ECI headset and device for DUT
varu|zZz is now known as varu
<Pali>
hm... great
<Pali>
those information about eci are really missing on internet
<Joerg-Neo900>
friend of mien will lend me his N95 and headset
<Joerg-Neo900>
yes, Nokia suckers never published that stuff, they want to licence it
<Joerg-Neo900>
Not even TI published docs for their ECI function block in TPS65951 (N9)
<Pali>
maybe we should be happy that nokia published source code for N9...
<Joerg-Neo900>
hehe
<Pali>
and implementation via sampling audio data on computer via sound card could be possible?
<Joerg-Neo900>
they use the ECI IP in GAIA so we can't learn much from that code
<Joerg-Neo900>
yes
<Joerg-Neo900>
but you need a way to switch micbias on and off FAST
<Joerg-Neo900>
and micbias is a buffered DC that's not meant to get switched fast
<Joerg-Neo900>
so you most likely will need additional hw
<Joerg-Neo900>
at least a FET controlled by arbitrary GPIO to short micbias to GND
<Joerg-Neo900>
unless you got some other means (like a MUX) to do such switching
<Joerg-Neo900>
or your PC can listen but not send, and ECI needs send to start session
<Joerg-Neo900>
weird, yes, but indeed ECI *needs* bidir data
<Joerg-Neo900>
though absilutely zilch command has any effect on _visible_ properties/behavior of headset
<Pali>
just switching micbias on/off generates eci data?
<Pali>
or something more complicated is needed?
<Joerg-Neo900>
yes, when you do it fast enough
<Pali>
sound card would be probably slow...
<Joerg-Neo900>
you physically can't thanks to buffer caps in micbias
<Joerg-Neo900>
but micbias has inpedance of 2k2R so you can short it as much as you want, to 'emulate' switching micbias
<Joerg-Neo900>
after all that's exactly what the simple pushbutton and ECI do too
<Joerg-Neo900>
just connect Source of FET to micbias, aka 2nd ring of TRRS, and Source to GND aka S of TRRS, then control Gate of FET with whatever signal you can control fast enough
<Joerg-Neo900>
(whatever signal) PAR or SER would come to mind. Or some sw controlled LED of your PC/laptop you abuse
<Pali>
now I'm trying to figure out how to enable/disable micbias on my computer sound card...
<Pali>
but stupid pulseaudio disallow me to access any alsa bits...
<Joerg-Neo900>
or HEY, *maybe* you simply connect 1st ring of TRRS (which is right channel audio out) via a 47uF to 2nd ring, and send the serial data via right channel ;-)
<Joerg-Neo900>
of course you don't want to use stereo headsets then any more
<Joerg-Neo900>
on the bright side you could buld an adapter that has such 47uF capacitor and you can plug/unplug that any time you want
<Joerg-Neo900>
such adapter obviously also would avoid routing same right-out signal to the jack where you plug in your headset. Instead it should route Tip (left/mono) to jack TIP (L) + 1st Ring (R)
<Joerg-Neo900>
a botch but cheap
<Joerg-Neo900>
needs quite some experimenting with capacitor size and audio-out-R signal amplitude and waveform to generate decent ECI outbound signal
<Joerg-Neo900>
and you need to make sure the amp goes high-Z when not sending signal, so inbound ECI data (and audio) doesn't get short to GND via amp output
<Joerg-Neo900>
HTH
<Joerg-Neo900>
n8
<Joerg-Neo900>
a last hint: `sudo systemctl stop pulse; alsamixer`
<Pali>
$ alsamixer -c 1
<Pali>
and now I see something useful
<Joerg-Neo900>
on N900 yes
<Pali>
on laptop
<Pali>
Card: HDA Intel PCH; Chip: Realtek ALC292
<Pali>
that is not pulseaudio! nice
<Joerg-Neo900>
ooh, so others also messed up ALSA? ;-P
<Pali>
if I start alsamixer without args I get: Card: PulseAudio
<Pali>
and -c 0 show me: Card: HDA Intel HDMI
<Pali>
looks like digital audio over hdmi
<Pali>
-c 1 is analog
<Joerg-Neo900>
-c 0 here. alas it seems for me they omitted micbias switch, though it OUGHT to be there
<Pali>
I do not see micbias switch on laptop via -c 0
<Joerg-Neo900>
though, *some* soundcards don't even support micbias
<Pali>
just dB gain of mic
<Joerg-Neo900>
but in my experience it's usually ALSA that's fscked
<Joerg-Neo900>
windows mixer tools expose micbias for same hw
<Joerg-Neo900>
maybe there's sth in /sys/*
<Joerg-Neo900>
but that's pretty nuch futile for ECI. Micbias has a 100uF buffer C or somesuch
<Pali>
just: Mic dB gain; Mic Boost dB gain; Mic mute
<Pali>
maybe it is mapped to Mic mute?
<Joerg-Neo900>
possible
<Joerg-Neo900>
simply plug in a cut wire and attach DVM
<Joerg-Neo900>
should be 2V5 roundabout
<Pali>
it is labeled "Capture" and values are "on" and "off"
<Joerg-Neo900>
generally speaking the generic soundcard has line-out, line-in/mix-in and those are TRS, not TRRS and thus pointless
<Joerg-Neo900>
s/mix/mic/
xes has joined #neo900
<Pali>
I have TRRS in notebook
<Joerg-Neo900>
unless your laptop has a headSET jack for combined headphones+mic, odds are you rather have a stereo in mic/line jack without support for any micbias
<Pali>
yes that combined headphones+mic
<Joerg-Neo900>
good, then you probabaly have hw support for micbias
<Joerg-Neo900>
alas ALSA never heard of it ;-)
<Pali>
probably heard, just pulseaudio conf did something strange...
<Pali>
going to look into /proc/asound
<Pali>
I remember that there was GUI tool with lot of checkboxes for alsa
<Joerg-Neo900>
nah, that's most likely a flaw in ALSA souncard PCM plugin
<Pali>
used for debugging
<Pali>
and with it I was able to configure sound card to send sound output to both jack and also to speakers
<Joerg-Neo900>
I hate PA but can't blame it this time
<Joerg-Neo900>
such tool is exactly what you need, yes
<Pali>
but only via that tool, alsamixer had not swich for that
<Joerg-Neo900>
or I2Cset
<Joerg-Neo900>
;-)
<Pali>
audio is not on i2c on my laptop
<Pali>
I scanned all i2c busses on my laptop
<Joerg-Neo900>
ugh, PCI then?
<Pali>
yes, pci
<Joerg-Neo900>
wait, it's still that microsoft intel HCI bridge, no?
<Joerg-Neo900>
HDA
<Joerg-Neo900>
whatever
<Pali>
00:1b.0 Audio device: Intel Corporation 8 Series/C220 Series Chipset High Definition Audio Controller (rev 04)
<Joerg-Neo900>
Card: HDA Intel HDMI
<Pali>
00:03.0 Audio device: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller (rev 06)
<Pali>
yes, HDA
<Joerg-Neo900>
that should be fairly standard
<Joerg-Neo900>
just possibly implemented in a not that usual way, to support TRRS
<Joerg-Neo900>
and micbias
<Joerg-Neo900>
the chip for sure can do it, just usually the PC manufs don't even connect the chip pins
<Joerg-Neo900>
and thus usual ALSA driver doesn't have MICBIAS