Twój Laptop Już Słyszy Hasła. Acoustic Keystroke Recovery W Praktyce

Keylogger nie musi czytać klawiatury z systemu.

Kiedy mówimy „keylogger”, większość osób widzi klasyczny obrazek: malware, hooki w systemie operacyjnym, podejrzany proces, może DLL injection, może coś grzebiącego przy GetAsyncKeyState, może rozszerzenie przeglądarki czy fałszywy agent z uprawnieniami użytkownika.

Ale keylogger nie musi czytać klawiatury z systemu. Czasem wystarczy, że słucha pokoju.

Brzmi jak tani clickbait? Tylko do momentu, w którym przypomnimy sobie, że komputery od dekad zdradzają informacje nie tylko przez sieć, aplikacje i logi, ale też przez fizykę: dźwięk, promieniowanie elektromagnetyczne, światło, drgania, pobór mocy, przewody, ekrany, mikrofony i przypadkowe sensory stojące na biurku.

Acoustic Keystroke Recovery to technika odzyskiwania informacji o naciśniętych klawiszach na podstawie dźwięku klawiatury. Nie chodzi o to, że człowiek „słyszy”, czy ktoś nacisnął A, S albo P. Człowiek zwykle nie rozróżnia tych kliknięć. Model statystyczny albo model ML może już próbować.

Punktem wyjścia do tego artykułu jest świeży materiał z pwn.guide, w którym autor pokazuje odzyskiwanie około 85% keystroke’ów z audio zarejestrowanego przez wbudowany mikrofon laptopa. To dobry trigger, ale sam temat jest znacznie starszy i ciekawszy niż jeden tutorial. Asonov i Agrawal pokazali praktyczny wariant akustycznego rozpoznawania klawiszy już w 2004 roku, Zhuang, Zhou i Tygar rozwinęli temat o modele językowe w 2005 roku, a późniejsze badania przeniosły problem w świat VoIP, Zooma, smartfonów, deep learningu i LLM-ów.

Najważniejsza teza jest prosta:

Hasło może wyciec bez malware, bez podatności w aplikacji i bez naruszenia protokołu kryptograficznego. Wystarczy kanał uboczny.

Klawiatura jako side-channel

Side-channel attack nie atakuje bezpośrednio algorytmu, protokołu ani aplikacji. Atakuje efekt uboczny działania systemu.

Szyfr może być matematycznie bezpieczny, a mimo to jego implementacja może zdradzać klucz przez czas wykonania operacji. System może nie logować hasła, a mimo to użytkownik może wystukać je na klawiaturze, która wydaje dźwięk. Laptop może nie wysyłać sekretu przez sieć, ale jego ekran, kabel albo układ elektroniczny może emitować sygnał skorelowany z przetwarzanymi danymi.

To jest cała filozofia side-channeli: nie pytamy systemu, co przetwarza. Patrzymy, jak zachowuje się fizyczne urządzenie, kiedy to robi.

NIST definiuje compromising emanations jako niezamierzone sygnały, które po przechwyceniu i analizie mogą ujawnić informacje transmitowane, odbierane, obsługiwane albo przetwarzane przez systemy telekomunikacyjne lub informatyczne. TEMPEST to z kolei obszar badania, kontroli i ograniczania takich niezamierzonych kompromitujących emanacji z urządzeń telekomunikacyjnych i systemów informatycznych.

To słowo — emanacje — brzmi trochę archaicznie. Ale technicznie jest bardzo trafne. Komputer nie jest abstrakcyjną maszyną logiczną. Komputer jest obiektem fizycznym. Ma przewody, układy elektroniczne, zasilanie, obudowę, ekran, klawiaturę, głośniki, mikrofony, kamery, wentylatory, cewki, porty i interfejsy radiowe.

Każdy z tych elementów może coś zdradzać.

Nie zawsze dużo. Nie zawsze praktycznie. Nie zawsze tanio. Ale w security nie pytamy tylko „czy to zadziała za każdym razem?”. Pytamy też:

Kto jest celem? Jaka jest wartość sekretu? Jakie są koszty atakującego? Jakie są alternatywy? Czy atak może być pasywny? Czy da się go wykryć?

W przypadku acoustic keystroke recovery odpowiedź jest niewygodna: dla masowego cybercrime’u to nadal raczej niszowy wektor. Dla szpiegostwa przemysłowego, operacji wywiadowczych, pracy z informacją niejawną, R&D, zarządów, prawników, dziennikarzy, administratorów produkcji i operatorów infrastruktury krytycznej — to już nie jest tylko ciekawostka.

Jak działa Acoustic Keystroke Recovery

Zobaczmy, co dzieje się, kiedy naciskasz klawisz.

Dla użytkownika to tylko klik. Dla mikrofonu to seria krótkich zdarzeń akustycznych i mechanicznych. Materiał z pwn.guide rozbija to na trzy intuicyjne komponenty: zdarzenie naciśnięcia klawisza, zdarzenie zwolnienia klawisza i rezonans obudowy. Ten ostatni element jest szczególnie ważny, bo różne klawisze są w innych miejscach klawiatury, inaczej pobudzają płytę klawiatury, inaczej przenoszą drgania przez chassis i mogą generować subtelnie różne ślady w sygnale audio.

To nie musi być różnica słyszalna dla człowieka. Modele klasyfikacyjne nie potrzebują „ładnego kliknięcia”. Potrzebują powtarzalnego wzorca.

W uproszczeniu pipeline wygląda tak:

dźwięk z mikrofonu
  -> wykrycie krótkich impulsów klawiszy
  -> wycięcie okien czasowych, np. kilkadziesiąt ms wokół kliknięcia
  -> ekstrakcja cech: spektrogram, log-mel spectrogram, MFCC, cepstrum
  -> klasyfikacja pojedynczych zdarzeń
  -> złożenie sekwencji znaków
  -> korekta kontekstowa: język, słownik, layout, model sekwencji, LLM

Atakujący nie musi „rozumieć dźwięku” tak jak człowiek. Wystarczy, że znajdzie zależność między sygnałem a klasą. Klasa może oznaczać konkretny klawisz, grupę klawiszy albo prawdopodobieństwo, że dany impuls należy do któregoś znaku.

Dawniej używano klasycznych metod sygnałowych i statystycznych: FFT, cepstrum, Hidden Markov Models, modele językowe. Dziś naturalnym krokiem są CNN-y, Vision Transformery i LLM-y używane jako warstwa korekty błędów.

Kluczowy szczegół: pojedynczy klawisz to tylko część problemu. Prawdziwa siła pojawia się przy sekwencji. Język ma strukturę. Hasła często mają wzorce. Użytkownicy piszą przewidywalnie. Administratorzy wpisują komendy, ścieżki, nazwy hostów, domeny, login, sudo, ssh, kubectl, az, aws, vault, prod, admin, root, token, backup, db, vpn.

Model nie musi być idealny. Wystarczy, że zmniejszy przestrzeń poszukiwań.

Jeżeli hasło ma 12 znaków i atakujący nie wie nic, problem jest ogromny. Jeżeli atak akustyczny powie mu, że na kilku pozycjach prawdopodobne są tylko 2–3 znaki, a reszta układa się w znany schemat organizacyjny, sytuacja zmienia się diametralnie.

To dlatego prace badawcze często nie mówią tylko o „trafieniu każdego klawisza”, ale o rankingach kandydatów, top-k accuracy, redukcji prób i korekcie sekwencji.

To nie zaczęło się od AI

Dzisiejsze nagłówki lubią format: „AI odczytuje hasła z dźwięku klawiatury”. Problem w tym, że taka narracja odcina temat od jego historii.

AI nie stworzyło tej klasy ataków. AI poprawiło ekonomię ich użycia.

IBM Research opublikował w 2004 roku pracę Asonova i Agrawala „Keyboard Acoustic Emanations”. Autorzy pokazali, że klawiatury PC, klawiatury notebooków, klawiatury telefoniczne i pady bankomatowe mogą być podatne na ataki oparte na rozróżnianiu dźwięków emitowanych przez różne klawisze. W ich podejściu do rozpoznawania klawiszy użyto sieci neuronowej.

Rok później Zhuang, Zhou i Tygar pokazali podejście, które brało około 10-minutowe nagranie pisania po angielsku i odzyskiwało do 96% wpisanych znaków. Co ważne, ich metoda nie wymagała etykietowanego nagrania treningowego, a w eksperymentach potrafiła redukować liczbę prób potrzebnych do odgadnięcia krótkich losowych haseł złożonych z liter.

To był bardzo ważny moment, bo pokazał coś, co wraca dzisiaj przy LLM-ach: język jest dodatkowym kanałem bocznym.

Nie wystarczy pytać: „czy klawisz T brzmi inaczej niż klawisz R?”. Trzeba też pytać: „jakie sekwencje znaków są prawdopodobne?”. Jeśli model słyszy coś w rodzaju:

p r o d _ d b _ a d ? i n

to nie trzeba geniuszu, żeby podejrzewać prod_db_admin.

Oczywiście hasła losowe, menedżery haseł i passphrase’y bez słownikowych schematów utrudniają tę warstwę. Ale praktyka bezpieczeństwa zna bolesną prawdę: ludzie i organizacje rzadko są tak losowe, jak chcą myśleć.

Od Skype do Zooma: call jako kanał boczny

Najbardziej praktyczny wariant nie polega dziś na tym, że ktoś podkłada mikrofon pod klawiaturę. Dużo częściej mikrofon już tam jest.

I sam go włączasz.

W 2016 roku praca „Don’t Skype & Type!” analizowała akustyczne podsłuchiwanie klawiatury przez VoIP. Autorzy zauważyli prosty problem: ludzie często piszą na klawiaturze podczas rozmów głosowych, a aplikacja VoIP zbiera i transmituje nie tylko głos, ale również dźwięki klawiszy. W badaniu uzyskano top-5 accuracy na poziomie 91,7% dla odgadywania losowo naciśniętego klawisza przy pewnej wiedzy o stylu pisania i modelu klawiatury ofiary.

W 2023 roku Harrison, Toreini i Mehrnezhad pokazali wariant deep learningowy: klasyfikację keystroke’ów laptopa z użyciem zintegrowanego mikrofonu smartfona oraz nagrań z Zooma. W abstrakcie pracy podają 95% accuracy dla nagrania z pobliskiego telefonu i 93% dla nagrania przez Zooma.

To jest bardzo istotne dla threat modelu.

Nie musimy zakładać scenariusza z filmów szpiegowskich. Wystarczy:

administrator jest na callu,
ma włączony mikrofon,
alt-tabuje do panelu chmurowego,
wpisuje hasło, token awaryjny albo komendę z sekretem,
nagranie spotkania trafia do chmury,
uczestnik zewnętrzny lub osoba z dostępem do nagrania ma audio.

Czy z tego zawsze da się odzyskać sekret? Nie.

Czy to jest wystarczająco realne, żeby w środowiskach wysokiego ryzyka dodać zasadę „nie wpisujemy sekretów przy aktywnym mikrofonie”? Tak.

I to jest różnica między paniką a inżynierskim security.

LLM jako korektor „literówek” w side-channelu

W klasycznym acoustic recovery model może pomylić pojedyncze klawisze. Tyle że błędy klasyfikatora nie muszą kończyć ataku. Mogą być wejściem dla kolejnego modelu.

W pracy USENIX WOOT 2025 „Making Acoustic Side-Channel Attacks on Noisy Keyboards Viable with LLM-Assisted Spectrograms’ ‘Typo’ Correction” badacze opisują podejście, które łączy klasyfikację spektrogramów z korektą kontekstową przy użyciu LLM. W ich threat modelu pojawiają się dwa scenariusze: nagranie telefonem oraz nagranie przez aplikacje konferencyjne, takie jak Zoom, Microsoft Teams lub Google Meet. Autorzy podają, że w warunkach kontrolowanych klasyfikacja VT osiągała ponad 96%, a w warunkach zaszumionych korekta LLM podnosiła dokładność odzyskiwania tekstu z około 50% do ponad 90% — w ich eksperymentalnym ustawieniu i dla tekstu naturalnego.

To ostatnie zastrzeżenie jest ważne: dla tekstu naturalnego.

LLM świetnie poprawia zdania, bo zdania mają semantykę. Jeżeli model widzi:

they attwnded a 0usi2 fectival

może odtworzyć sens. Jeżeli widzi:

7xQ!v2@Lm9#p

nie ma takiej samej przewagi kontekstowej.

Ale branżowo to i tak zmienia grę. Wiele sekretów wpisywanych przez ludzi nie jest idealnie losowych. Komendy administracyjne mają składnię. Ścieżki mają strukturę. Tokeny bywają poprzedzone nazwą zmiennej. Użytkownicy wpisują nazwy projektów, domen, klientów, repozytoriów, klastrów, tenantów i środowisk.

LLM nie musi „złamać kryptografii”. Może po prostu posprzątać szum.

Najnowszy kierunek badań idzie jeszcze dalej. W 2026 roku pojawiła się praca DECKER, zaakceptowana do AsiaCCS’26, która opisuje dataset HEAR obejmujący 53 uczestników i 37 laptopowych klawiatur w kilku realistycznych trybach nagrywania: zewnętrzny mikrofon, mikrofon urządzenia oraz streaming VoIP. Autorzy analizują generalizację między klawiaturami, adaptację do hałasu, bias użytkownika i użycie LLM do poprawy sekwencji na poziomie zdań.

To jest bardzo ważny sygnał. Historyczny problem Acoustic Side-Channel Attacks polegał na tym, że wiele PoC działało dobrze dla konkretnej osoby, konkretnej klawiatury, konkretnego mikrofonu i konkretnego pokoju. Nowe badania próbują uderzyć dokładnie w tę słabość: generalizację, hałas, cross-keyboard, cross-user.

Czy to znaczy, że każdy laptop od jutra zdradza wszystkie hasła każdemu uczestnikowi spotkania? Nie.

Czy to znaczy, że granica praktyczności zaczyna się przesuwać? Tak.

Elektromagnetyczny kuzyn: kabel klawiatury też kiedyś „mówił”

Tu dochodzimy do rzeczy, o której wspomniałeś: kiedyś hasła i znaki można było próbować odczytywać po falach wzbudzonych w kablu klawiatury albo po elektromagnetycznych emanacjach urządzeń.

To nie jest miejska legenda.

W 2009 roku Vuagnoux i Pasini z EPFL/LASEC opisali kompromitujące emanacje elektromagnetyczne klawiatur przewodowych i bezprzewodowych. Według opisu EPFL przetestowali 12 modeli klawiatur z lat 2001–2008: PS/2, USB, wireless i laptopowe. Wszystkie były podatne na co najmniej jeden z badanych wariantów, a najlepszy praktyczny atak odzyskał 95% naciśnięć klawiszy klawiatury PS/2 z odległości do 20 metrów, nawet przez ściany.

To jest dokładnie ten sam rodzaj myślenia, tylko inny sensor.

• W acoustic recovery sensorem jest mikrofon.
• W wariancie EM sensorem jest antena albo odbiornik SDR.
• W wariancie optycznym sensorem może być kamera, odbicie w okularach albo migotanie LED-a.
• W wariancie termicznym sensorem może być kamera termowizyjna.
• W wariancie mechanicznym sensorem może być akcelerometr telefonu leżącego obok klawiatury.

Ale idea jest ta sama:

sekret -> operacja fizyczna -> efekt uboczny -> sensor -> analiza -> inferencja sekretu

Dawniej środowiska wojskowe i rządowe traktowały takie ryzyko bardzo serio, bo dla nich „mało prawdopodobne” nie oznacza „nieważne”. Jeśli przetwarzasz informację niejawną albo strategicznie istotną, musisz brać pod uwagę przeciwnika z czasem, sprzętem i cierpliwością.

Stąd ekranowane pomieszczenia, kontrolowane strefy, odległość od okien, ekranowanie przewodów, filtry, separacja obwodów i różnego rodzaju praktyki EMSEC. NIST definiuje EMSEC jako część communications security, której celem jest uniemożliwienie nieautoryzowanym osobom pozyskania wartościowych informacji przez przechwycenie i analizę kompromitujących emanacji.

W tym kontekście „komputer w klatce z drutu” nie brzmi jak paranoja. Brzmi jak fizyka.

CRS w memorandum o TEMPEST przypomina, że historyczne metody ograniczania takich ataków obejmowały dystansowanie, ekranowanie, maskowanie i filtrowanie. Wprost wspomina też o metalowych klatkach w pomieszczeniach oraz SCIF-ach jako przykładzie shielding/hardening.

Van Eck, TEMPEST i „monitor jako nadajnik”

Jeżeli temat klawiatur po kablu brzmi egzotycznie, to warto cofnąć się jeszcze dalej.

Wim van Eck opublikował w 1985 roku pracę o podsłuchiwaniu monitorów przez odbiór i dekodowanie elektromagnetycznych zakłóceń generowanych przez video display units. Abstract pracy mówi wprost o możliwości eavesdroppingu na obraz przez przechwytywanie i dekodowanie elektromagnetycznych interferencji emitowanych przez sprzęt.

To później zaczęto potocznie kojarzyć jako Van Eck phreaking.

W praktyce oznaczało to coś niewygodnego: ekran, który miał tylko wyświetlać informację lokalnie, mógł w pewnych warunkach stać się źródłem sygnału dla odbiornika poza pomieszczeniem. Nie dlatego, że system operacyjny wysłał dane. Dlatego, że elektronika pracująca z sygnałem obrazu emitowała coś, co dało się skorelować z tym, co było na ekranie.

CRS przypomina też historyczny epizod z Bell Labs podczas II wojny światowej: podczas testów sprzętu kryptograficznego inżynierowie zauważyli reakcję na odległym oscyloskopie, a dalsza analiza pozwalała odczytywać plaintext przetwarzany przez urządzenie.

Właśnie dlatego warto pokazać Acoustic Keystroke Recovery nie jako „nowy hack z AI”, ale jako kolejną generację starego problemu:

TEMPEST / EMSEC:
  urządzenie przetwarza sekret
  -> emituje kompromitujący sygnał
  -> atakujący przechwytuje sygnał
  -> rekonstruuje informację

Acoustic Keystroke Recovery:
  człowiek wpisuje sekret
  -> klawiatura emituje dźwięk i drgania
  -> mikrofon zbiera sygnał
  -> model rekonstruuje prawdopodobne klawisze

Zmieniły się sensory. Zmieniły się modele. Zmieniła się skala dostępności sprzętu. Ale zasada została.

RED/BLACK, czyli separacja nie była ozdobą dokumentacji

W środowiskach przetwarzających informacje niejawne często pojawia się koncepcja RED/BLACK. W uproszczeniu RED to obszar, obwody lub systemy obsługujące informację wrażliwą/niejawną w postaci niezaszyfrowanej, a BLACK to część po stronie mniej wrażliwej albo zaszyfrowanej. NIST definiuje RED/BLACK concept jako separację obwodów, komponentów, sprzętu i systemów obsługujących informacje bezpieczeństwa narodowego od tych, które takich informacji nie obsługują.

Dlaczego to ma znaczenie przy naszym temacie?

Bo acoustic keystroke recovery to bardzo dobry przykład sytuacji, w której zwykłe myślenie „dane są w systemie X, więc chronię system X” jest za wąskie.

Załóżmy, że masz:

RED:
  laptop administratora
  sesja PAM
  dostęp do produkcji
  hasło break-glass
  recovery key

BLACK:
  aplikacja wideokonferencyjna
  uczestnicy spotkania
  nagranie rozmowy
  transkrypcja AI
  telefon na biurku

Jeżeli użytkownik wpisuje sekret RED przy aktywnym mikrofonie BLACK, to rozdział zaczyna się rozmywać.

Nie dlatego, że ktoś „złamał szyfrowanie Teams”.
Nie dlatego, że EDR zawiódł.
Nie dlatego, że protokół SSO był źle zaprojektowany.

Dlatego, że fizyczny efekt wpisywania sekretu trafił do innego systemu.

To jest bardzo ważny punkt dla architektów bezpieczeństwa: separacja logiczna nie zawsze wystarcza, gdy sensor fizyczny zbiera sygnały z obu światów.

Realny threat model: kto powinien się tym przejmować

Nie każdy użytkownik powinien dziś budować klatkę Faradaya wokół biurka. To byłaby paranoja, nie bezpieczeństwo.

Ale nie każda organizacja ma taki sam profil ryzyka.

Atak acoustic keystroke recovery ma największy sens tam, gdzie spełnione są przynajmniej niektóre warunki:

cel jest wysokowartościowy,
sekret jest wpisywany ręcznie,
mikrofon znajduje się blisko klawiatury,
atakujący ma dostęp do audio albo nagrania,
środowisko jest powtarzalne,
użytkownik pisze przewidywalnie,
tekst ma strukturę językową lub techniczną,
atak może być pasywny i trudny do wykrycia.

W raporcie CRS o TEMPEST pojawia się bardzo rozsądna ocena: tradycyjne cyberataki często skuteczniej dają bezpośredni dostęp do danych, więc side-channel bywa atrakcyjny raczej w szczególnych sytuacjach, między innymi dlatego, że może umożliwiać pasywne zbieranie informacji bez instalowania malware i bez ryzyka wykrycia związanego z kompromitacją endpointa.

To zdanie dobrze ustawia priorytety.

Dla przeciętnego ransomware crew łatwiej jest ukraść token z przeglądarki, wyłudzić MFA, kupić access brokera albo wykorzystać źle skonfigurowany VPN.

Dla przeciwnika wywiadowczego, który nie chce dotknąć endpointa, bo endpoint jest dobrze monitorowany, side-channel może być ciekawy.

Dla insidera z dostępem do nagrań spotkań — też.

Dla prywatnego detektywa, surveillance mercenary albo operatora z fizycznym dostępem do sali konferencyjnej — również.

W marcu 2026 roku senator Ron Wyden i kongresmenka Shontel Brown poprosili GAO o analizę zagrożeń TEMPEST-style także dla sektora prywatnego i elektroniki konsumenckiej. W liście wskazali, że takie metody nie dotyczą wyłącznie kontrwywiadu rządowego, ale mogą być użyte przeciwko firmom w celu kradzieży strategicznie istotnych technologii. Zwrócili też uwagę, że rząd USA nie narzucił producentom elektroniki konsumenckiej wymagań dotyczących technicznych countermeasures przeciwko takim zagrożeniom.

To nie znaczy, że jutro każdy laptop dostanie certyfikację TEMPEST. Znaczy to, że temat zaczyna wracać na poziom polityki, regulacji i odpowiedzialności producentów.

Scenariusz 1: administrator na Teamsie

Najprostszy scenariusz wygląda tak:

09:00  Stand-up zespołu infrastruktury.
09:12  Administrator zostaje poproszony o szybkie sprawdzenie problemu na produkcji.
09:13  Ma włączony mikrofon, bo odpowiada zespołowi.
09:14  Alt-tab do terminala.
09:14  ssh bastion-prod
09:14  sudo -i
09:15  wpisanie hasła albo passphrase do klucza.
09:16  spotkanie jest nagrywane.
09:17  nagranie trafia do przestrzeni projektowej.

W klasycznym modelu ryzyka pytamy:

Czy połączenie SSH jest szyfrowane?
Czy MFA działa?
Czy PAM nagrywa sesję?
Czy EDR widzi podejrzane procesy?
Czy admin ma least privilege?

W modelu side-channel trzeba dodać:

Czy w momencie wpisywania sekretu aktywny był mikrofon?
Czy spotkanie było nagrywane?
Kto ma dostęp do nagrania?
Czy transkrypcja/AI summary obejmuje audio z tego fragmentu?
Czy endpoint administracyjny jest tym samym endpointem, na którym działa call?
Czy w sali było inne urządzenie rejestrujące?

To nie jest science fiction. To jest brak jednego kroku w procedurze.

Przed wpisaniem sekretu:
  mute -> wpisz sekret -> unmute

Jeszcze lepiej:

nie wpisuj sekretów ręcznie,
użyj passkey / FIDO2 / PAM / krótkotrwałego tokena / password managera,
a sesje privileged wykonuj poza aktywnym callem.

Scenariusz 2: telefon obok laptopa

Drugi wariant jest jeszcze bardziej codzienny.

Telefon leży 15–30 cm od klawiatury. Użytkownik ma rozmowę na głośnomówiącym, nagrywa voice note albo używa aplikacji, która ma dostęp do mikrofonu. Nie trzeba specjalistycznego mikrofonu. Badanie z 2023 roku pokazało użycie zintegrowanego mikrofonu smartfona i off-the-shelf algorytmów do klasyfikacji keystroke’ów laptopa.

Praktyczny wniosek jest prosty: w salach wysokiej poufności prywatny telefon na biurku nie jest neutralnym przedmiotem. Jest zbiorem sensorów:

mikrofon,
kamera,
akcelerometr,
żyroskop,
magnetometr,
radio,
Bluetooth,
Wi-Fi,
modem,
system operacyjny,
aplikacje,
chmura producenta,
chmury aplikacji.

Nie każdy sensor jest używany do ataku. Ale każdy sensor poszerza threat model.

Scenariusz 3: nagranie spotkania jako wrażliwe dane

Organizacje bardzo często traktują nagrania spotkań jak materiał biurowy. Ktoś wrzuca recording do kanału, ktoś robi automatyczne podsumowanie, ktoś trzyma nagranie przez rok, ktoś udostępnia zewnętrznemu dostawcy.

A teraz dodajmy do tego side-channel.

Nagranie spotkania może zawierać:

treść rozmowy,
ekrany udostępniane przez uczestników,
dźwięk klawiatury,
nazwy systemów wypowiedziane w tle,
fragmenty rozmów spoza spotkania,
dźwięki powiadomień,
wzorce operacyjne pracy zespołu,
momenty logowania do systemów,
komendy wpisywane podczas rozmowy.

W klasycznym DLP nagranie może przejść jako „video meeting recording”. Ale z punktu widzenia side-channeli może być paczką metadanych o pracy zespołu.

To nie oznacza, że każde nagranie trzeba kasować. Oznacza, że nagrania spotkań technicznych, administracyjnych, prawnych, zarządczych i R&D powinny mieć klasyfikację, retencję i dostęp adekwatny do ryzyka.

Scenariusz 4: wariant elektromagnetyczny

W środowisku o podwyższonym ryzyku atakujący nie musi używać mikrofonu. Może użyć odbiornika RF, anteny, SDR albo innego sensora elektromagnetycznego.

To jest droższe, trudniejsze i bardziej zależne od środowiska niż zwykłe nagranie audio, ale bywa bardziej atrakcyjne tam, gdzie audio jest kontrolowane, a emanacje EM nie są testowane.

EPFL pokazało, że nowoczesne wtedy klawiatury przewodowe i bezprzewodowe mogą generować kompromitujące emanacje, a najlepszy praktyczny atak w ich badaniach odzyskiwał 95% keystroke’ów z PS/2 z 20 metrów, także przez ściany.

Dlatego w wojsku, dyplomacji i środowiskach klasyfikowanych stosuje się strefy, dystanse, ekranowanie, zasady dla przewodów, separację RED/BLACK i urządzenia spełniające określone wymagania emisyjne.

W zwykłej firmie to byłby overkill. W środowisku informacji niejawnej — podstawy inżynierii bezpieczeństwa.

Co ogranicza ten atak

Tu trzeba zatrzymać hype.

Acoustic Keystroke Recovery nie jest magicznym mikrofonem, który z każdego pokoju odzyska każde hasło. Są realne ograniczenia.

Hałas

Rozmowa, wentylator, klimatyzacja, muzyka, hałas ulicy, inne osoby piszące na klawiaturze, pogłos, mechaniczna klawiatura obok, kompresja audio, noise suppression — to wszystko pogarsza sygnał.

Nowsze badania właśnie dlatego idą w kierunku noise robustness. USENIX WOOT 2025 zwraca uwagę, że wcześniejsze podejścia potrafiły działać dobrze w czystych warunkach, ale pogarszać wyniki w środowiskach realistycznych z hałasem.

Dopasowanie do użytkownika i klawiatury

Modele często działają najlepiej w warunku:

ten sam użytkownik,
ta sama klawiatura,
ten sam mikrofon,
ten sam dystans,
podobne środowisko,
podobny styl pisania.

Zhuang, Zhou i Tygar podkreślali, że dźwięki nie są jednolite między różnymi instancjami urządzeń i środowiskami, a ta sama klawiatura używana przez różne osoby może emitować różne dźwięki.

To jest jeden z powodów, dla których prace typu DECKER są ważne: próbują poprawić generalizację między klawiaturami, użytkownikami i warunkami.

Losowe hasła są trudniejsze niż tekst

Naturalny tekst pomaga modelowi. Losowy sekret przeszkadza modelowi.

To dlatego passphrase z menedżera haseł, długi losowy token, FIDO2, WebAuthn czy passkey znacząco zmieniają praktyczność ataku. Nie dlatego, że wyciszają klawiaturę, ale dlatego, że ograniczają sytuacje, w których człowiek wystukuje sekret lub wprowadzają sekret, którego model językowy nie może łatwo „naprawić”.

FIDO Alliance opisuje passkeys jako technologię zastępującą hasła, odporną na phishing, silną i zaprojektowaną bez współdzielonych sekretów. W3C WebAuthn definiuje API do użycia silnych, scoped, public-key-based credentials przez aplikacje webowe.

Special keys i edycja tekstu

Wpisywanie hasła to nie tylko znaki. Są też:

Shift,
Backspace,
Enter,
Tab,
Caps Lock,
Ctrl,
Alt,
znaki specjalne,
układy klawiatury,
martwe klawisze,
poprawki,
wklejanie,
autouzupełnianie.

Jeżeli model źle rozpozna Backspace albo Shift, wynik może się rozsypać. Jeżeli użytkownik wkleja sekret z menedżera haseł, nie ma sekwencji klawiszy hasła do podsłuchania — choć nadal mogą istnieć inne kanały ryzyka.

Brak kontekstu

Jeżeli atakujący nie wie, kiedy użytkownik wpisuje sekret, czym jest środowisko, jaki jest layout klawiatury, czy używa QWERTY/QWERTZ/AZERTY, czy wpisuje po polsku/angielsku, czy pisze hasło czy zwykły tekst, skuteczność i wartość danych spada.

Ale znowu: w praktyce atakujący często ma kontekst. Wie, że o 10:00 jest deployment. Wie, że admin loguje się do prod. Wie, że firma używa konkretnej chmury. Wie, że podczas incident bridge ktoś będzie wpisywał komendy.

Side-channel rzadko działa w próżni. Działa jako element większego rozpoznania.

Dlaczego to ma znaczenie dla branży

Największy błąd to potraktować ten temat jako „fajny research z mikrofonem”.

To jest dużo szerszy sygnał.

1. Endpoint security musi zejść do warstwy sensorów

EDR-y i XDR-y bardzo dobrze nauczyły się patrzeć na:

procesy,
pliki,
rejestr,
pamięć,
skrypty,
sieć,
command line,
parent-child process tree,
DLL-e,
persistence,
credential dumping.

Ale mikrofon, kamera, akcelerometr, głośnik, port USB, kabel HDMI, ekran, touchpad i klawiatura to też powierzchnia ataku.

Nie każda organizacja potrzebuje detekcji acoustic side-channel. Ale coraz więcej organizacji powinno zadawać pytania:

Które aplikacje mają dostęp do mikrofonu?
Czy privileged workstation może prowadzić wideokonferencje?
Czy administrator może mieć Teams/Zoom na tej samej maszynie, na której robi dostęp produkcyjny?
Czy nagrania spotkań technicznych mają retencję i klasyfikację?
Czy endpoint pokazuje użytkownikowi hardware’owy stan mikrofonu?
Czy MDM może ograniczyć audio capture w grupach wysokiego ryzyka?

To nie jest tylko privacy. To jest security.

2. Wideokonferencje są elementem threat modelu

Przez lata bezpieczeństwo wideokonferencji koncentrowało się na:

kto może dołączyć,
czy spotkanie jest zahasłowane,
czy link wyciekł,
czy nagranie jest dostępne,
czy screen sharing ujawnia dane,
czy chat zawiera sekrety.

Teraz warto dodać:

czy podczas spotkania wpisujemy sekrety,
czy call działa na tej samej stacji co dostęp uprzywilejowany,
czy nagranie może zawierać kanały boczne,
czy automatyczna transkrypcja i AI summary przetwarzają fragmenty audio,
czy uczestnicy zewnętrzni dostają czysty strumień dźwięku klawiatury.

To jest szczególnie ważne w incident response. Podczas incydentu ludzie są zestresowani, dużo mówią, dużo piszą, logują się do systemów awaryjnych i czasem używają break-glass credentials. Dokładnie wtedy zasady OPSEC najczęściej się rozjeżdżają.

3. DLP nie widzi wszystkiego

DLP widzi plik, upload, mail, formularz, czasem clipboard, czasem treść w SaaS.

DLP niekoniecznie widzi, że mikrofon zebrał dźwięk wpisywania hasła, a potem ktoś poza organizacją wykonał inferencję.

To jest blind spot.

Nie oznacza to, że mamy wyrzucić DLP. Oznacza to, że DLP nie może być jedynym modelem myślenia o wycieku danych. Wyciek nie zawsze wygląda jak secret.txt wysłany na prywatnego Gmaila.

Czasem wygląda jak:

meeting-recording-2026-05-incident-bridge.mp4

4. AI zwiększa wartość zaszumionych danych

To jest chyba najważniejszy branżowy wniosek.

AI nie tylko automatyzuje znane ataki. AI przesuwa granicę tego, co opłaca się analizować.

Dawniej wiele side-channeli było „możliwych, ale drogich”. Trzeba było mieć specjalistyczną wiedzę, dużo ręcznej analizy i bardzo dobre warunki. Modele ML/LLM zmieniają ekonomię:

mniej idealny sygnał,
więcej automatycznej korekty,
tańsza klasyfikacja,
szybsze iteracje,
lepsza analiza kontekstu,
łatwiejsze łączenie wielu słabych sygnałów.

To dotyczy nie tylko klawiatur. Dotyczy RF, wideo, audio, zachowań użytkownika, telemetryki, logów, metadanych, ruchu sieciowego i patternów operacyjnych.

5. Secure workspace wraca do gry

Przez ostatnie lata branża mocno poszła w chmurę, IAM, EDR, CNAPP, CI/CD, Kubernetes, SBOM, supply chain i zero trust. To potrzebne. Ale ten temat przypomina, że security nie kończy się na API i logach.

Biurko też jest powierzchnią ataku.

Sala konferencyjna też.
Mikrofon konferencyjny też.
Telefon na stole też.
Okno na ulicę też.
Przewód klawiatury też.
Kabel HDMI też.
Nagranie spotkania też.

Nie trzeba budować bunkra dla każdego zespołu. Ale trzeba umieć rozróżnić zwykłe środowisko biurowe od:

pracy z informacją niejawną,
R&D o wysokiej wartości,
rozmów M&A,
sesji zarządu,
obsługi incydentu,
administracji produkcji,
dostępu do systemów krytycznych,
operacji prawniczych,
pracy dziennikarskiej ze źródłami.

W takich miejscach secure workspace nie jest fanaberią. Jest kontrolą bezpieczeństwa.

Jak się bronić bez budowania bunkra

Nie zaczynamy od klatki Faradaya. Zaczynamy od prostych zasad, które mają bardzo dobry stosunek kosztu do efektu.

Zasada pierwsza: nie wpisuj sekretów przy aktywnym mikrofonie

To jest najprostszy i najbardziej praktyczny wniosek.

Przed wpisaniem:

hasła,
passphrase do klucza SSH,
recovery key,
seed phrase,
tokena awaryjnego,
sekretu w zmiennej środowiskowej,
komendy z hasłem w argumencie,
kodu jednorazowego,
danych klienta,
fragmentu konfiguracji produkcyjnej,

zrób:

mute -> wpisz sekret -> unmute

Jeszcze lepiej:

zakończ call -> wykonaj operację privileged -> wróć do calla

W środowisku wysokiego ryzyka:

osobna stacja do calli,
osobna stacja do administracji,
brak mikrofonu na privileged access workstation,
brak prywatnych telefonów w sali,
brak nagrywania podczas sesji administracyjnych.

Zasada druga: ogranicz ręczne wpisywanie sekretów

Najlepszy dźwięk hasła to taki, którego nie ma.

W praktyce:

password manager z autofill zamiast ręcznego wpisywania,
passkeys / WebAuthn / FIDO2,
PAM z brokerowaniem sesji,
krótkotrwałe tokeny,
SSO z phishing-resistant MFA,
just-in-time access,
brak haseł produkcyjnych znanych człowiekowi,
zakaz wpisywania sekretów w command line.

NIST SP 800-63-4 opisuje dobór poziomów assurance dla identity, authentication i federation zależnie od ryzyka, a aktualizacja wskazuje między innymi nowe opcje dla phishing-resistant authentication.

Passkeys nie rozwiązują każdego problemu. Jeżeli użytkownik odblokowuje passkey PIN-em wpisywanym na tej samej klawiaturze, jakiś kanał akustyczny nadal może istnieć. Ale passkeys eliminują najgorszy element: długi, współdzielony sekret wpisywany ręcznie i możliwy do ponownego użycia.

Zasada trzecia: traktuj nagrania spotkań jak dane wrażliwe

Dla spotkań technicznych i administracyjnych warto wprowadzić zasady:

nie nagrywamy sesji, w których wpisywane są sekrety,
nie wpisujemy sekretów podczas nagrywanych spotkań,
nagrania incident bridge mają krótką retencję,
nagrania spotkań z vendorami nie zawierają operacji privileged,
dostęp do nagrań jest ograniczony,
automatyczne transkrypcje są objęte klasyfikacją danych,
AI summaries nie są włączone dla spotkań wysokiej poufności bez oceny ryzyka.

To nie jest walka z produktywnością. To jest higiena danych.

Zasada czwarta: rozdziel urządzenia według funkcji

W wielu organizacjach jeden laptop robi wszystko:

mail,
Teams,
Zoom,
Slack,
VPN,
SSH,
RDP,
kubectl,
panel chmurowy,
hasła,
prywatne strony,
prezentacje,
demo dla vendora.

To jest wygodne. Ale dla ról uprzywilejowanych warto rozważyć inny model:

laptop użytkownika:
  komunikacja, mail, dokumenty, spotkania

PAW / SAW:
  dostęp administracyjny, brak Teams/Zoom, ograniczony internet, brak mikrofonu

jump host / PAM:
  kontrolowane sesje, nagrywanie operacji, MFA, JIT access

Jeżeli PAW nie ma mikrofonu i nie prowadzi spotkań, acoustic keystroke recovery z calla przestaje być praktycznym wektorem dla tej klasy dostępu.

Zasada piąta: fizyczny OPSEC dla pomieszczeń wysokiego ryzyka

Dla zwykłego open space’u wystarczy zdrowy rozsądek.

Dla sali zarządu, R&D, negocjacji M&A, SOC war roomu, labu z tajemnicą przedsiębiorstwa albo pracy z informacją niejawną trzeba ostrzej:

brak prywatnych telefonów,
kontrola mikrofonów konferencyjnych,
mute domyślny,
brak nagrywania bez zgody i klasyfikacji,
procedura przed wpisywaniem sekretów,
akustyczne maskowanie tylko tam, gdzie ma sens,
ekranowanie / TEMPEST / EMSEC tylko dla uzasadnionych klas ryzyka,
odległość od okien i ścian zewnętrznych w środowiskach wysokiej klasyfikacji,
kontrola przewodów, portów i urządzeń peryferyjnych.

CRS opisuje historyczne metody ograniczania TEMPEST jako distancing, shielding, masking i filtering. To nadal dobre kategorie myślenia, nawet jeśli nie każda organizacja wdroży je w wersji wojskowej.

Praktyka defensywna: co można sprawdzić od razu

Nie będziemy budować keyloggera. Nie ma potrzeby publikowania kompletnego kodu do odzyskiwania klawiszy. Ale możemy pokazać bezpieczne rzeczy: jak sprawdzić uprawnienia mikrofonu, jak zobaczyć aktywne źródła audio i jak myśleć o detekcji.

Windows: przegląd uprawnień mikrofonu

Na Windows informacje o zgodach aplikacji mogą znajdować się w CapabilityAccessManager. To nie jest idealny audyt aktywnego użycia mikrofonu, ale pozwala zobaczyć, jakie aplikacje miały przyznane/odmówione uprawnienia.

Przykład PowerShell:

$paths = @(
  "HKCU:\Software\Microsoft\Windows\CurrentVersion\CapabilityAccessManager\ConsentStore\microphone",
  "HKLM:\Software\Microsoft\Windows\CurrentVersion\CapabilityAccessManager\ConsentStore\microphone"
)

foreach ($path in $paths) {
    if (Test-Path $path) {
        Write-Host "`n=== $path ==="
        Get-ChildItem $path -ErrorAction SilentlyContinue | ForEach-Object {
            $props = Get-ItemProperty $_.PsPath -ErrorAction SilentlyContinue
            [PSCustomObject]@{
                App   = $_.PSChildName
                Value = $props.Value
                LastUsedStartTime = $props.LastUsedTimeStart
                LastUsedStopTime  = $props.LastUsedTimeStop
            }
        } | Format-Table -AutoSize
    }
}

Interpretacja:

Allow  -> aplikacja ma zgodę
Deny   -> aplikacja nie ma zgody
Prompt -> system może pytać użytkownika

W praktyce warto porównać wynik z polityką:

Czy przeglądarki mają mikrofon?
Czy aplikacje niekonferencyjne mają mikrofon?
Czy narzędzia developerskie mają mikrofon?
Czy PAW ma jakąkolwiek aplikację z mikrofonem?

macOS: TCC i mikrofon

Na macOS uprawnienia prywatności są kontrolowane przez TCC. W zależności od wersji systemu i uprawnień terminala można podejrzeć wpisy dla mikrofonu.

sqlite3 "$HOME/Library/Application Support/com.apple.TCC/TCC.db" \
"SELECT service, client, auth_value, last_modified
 FROM access
 WHERE service='kTCCServiceMicrophone';"

Reset zgód mikrofonu dla użytkownika:

tccutil reset Microphone

Dla środowisk zarządzanych MDM/Jamf/Intune warto mieć politykę, która definiuje, które aplikacje mogą prosić o mikrofon, a które nie powinny mieć takiej możliwości.

Linux: PipeWire / PulseAudio

Na wielu współczesnych dystrybucjach używany jest PipeWire lub PulseAudio. Aktywne nagrywanie można czasem zobaczyć przez pactl.

pactl list source-outputs short

Bardziej szczegółowo:

pactl list source-outputs

PipeWire status:

wpctl status

Procesy korzystające z urządzeń audio:

fuser -v /dev/snd/*

Logi użytkownika dla PipeWire:

journalctl --user -u pipewire -u pipewire-pulse --since "1 hour ago"

To nie jest pełny system detekcji. To jest szybki audyt operatorski. W środowisku produkcyjnym sensowniejsze jest centralne zbieranie telemetryki z endpointów i polityki MDM/EDR.

Przykładowa logika detekcji dla SOC

Nie ma jednego uniwersalnego eventu „ktoś właśnie użył mikrofonu” działającego identycznie na każdym OS, EDR i wersji systemu. Ale logika detekcji może wyglądać tak:

Nazwa reguły:
  Audio capture on privileged workstation

Warunek:
  host.tag == "PAW" OR host.group == "PrivilegedAccess"
  AND process.accesses_microphone == true

Wykluczenia:
  approved_process IN ["approved_secure_conferencing_app"]
  AND approved_time_window == true
  AND user.role != "production_admin"

Akcja:
  medium/high alert
  enrich: process, parent_process, user, meeting app, network destination

Dla zwykłych laptopów alert na każdy mikrofon byłby bezużyteczny. Dla PAW — bardzo wartościowy.

Inna reguła:

Nazwa reguły:
  Meeting app active during privileged access

Warunek:
  process.name IN ["Teams", "Zoom", "Meet browser tab", "Discord", "Slack Huddle"]
  AND privileged_session.active == true

Akcja:
  user notification + SOC event
  "Do not enter secrets while microphone is active"

To można wdrożyć jako twardą blokadę lub miękki guardrail.

Przykładowy syntetyczny log:

2026-05-22T09:14:33Z host=PAW-017 user=adm-jkowalski
event=audio_capture_started process=Teams.exe pid=4832
parent=explorer.exe mic_device="Integrated Microphone"

2026-05-22T09:14:41Z host=PAW-017 user=adm-jkowalski
event=privileged_session_started target=bastion-prod method=ssh

2026-05-22T09:14:42Z alert=MeetingAppDuringPrivilegedSession
severity=high action=user_prompt
message="Microphone active while privileged session started. Mute or terminate call before entering secrets."

Taki alert nie mówi „ktoś przeprowadza acoustic keystroke recovery”. Mówi: warunki do kanału bocznego pojawiły się na stacji, na której nie powinny się pojawić.

To jest wystarczająco dobre dla defensywy.

Mini-lab defensywny: zobacz spektrogram, nie buduj keyloggera

Można pokazać czytelnikowi fizykę bez publikowania ofensywnego narzędzia.

Cel: zobaczyć, że naciśnięcie klawisza generuje krótkie, widoczne zdarzenie w spektrogramie. Bez etykietowania klawiszy. Bez klasyfikacji. Bez modelu. Bez odzyskiwania haseł.

Instalacja:

python -m venv venv
source venv/bin/activate
pip install sounddevice numpy scipy matplotlib

Kod:

import sounddevice as sd
import numpy as np
import matplotlib.pyplot as plt
from scipy.signal import spectrogram

SAMPLE_RATE = 44100
DURATION = 5

print("Nagrywanie 5 sekund. Naciśnij kilka klawiszy na własnej klawiaturze.")
audio = sd.rec(int(DURATION * SAMPLE_RATE), samplerate=SAMPLE_RATE, channels=1)
sd.wait()

audio = audio[:, 0]

frequencies, times, spec = spectrogram(
    audio,
    fs=SAMPLE_RATE,
    nperseg=1024,
    noverlap=768
)

plt.figure(figsize=(12, 6))
plt.pcolormesh(times, frequencies, 10 * np.log10(spec + 1e-12), shading="auto")
plt.ylim(0, 12000)
plt.xlabel("Czas [s]")
plt.ylabel("Częstotliwość [Hz]")
plt.title("Spektrogram krótkiego nagrania klawiatury")
plt.colorbar(label="Moc [dB]")
plt.tight_layout()
plt.show()

Co pokazuje ten lab?

Nie „jak kraść hasła”.

Pokazuje, że klawisz nie jest abstrakcyjnym eventem systemowym. To fizyczne zdarzenie z sygnaturą akustyczną. Widać impulsy. Widać pasma. Widać, że mikrofon zbiera coś więcej niż mowę.

I tyle wystarczy do edukacji.

Checklista dla użytkowników

Przed spotkaniem:

[ ] Czy spotkanie będzie nagrywane?
[ ] Czy będę wykonywać operacje administracyjne?
[ ] Czy będę wpisywać hasło, passphrase, token, recovery key?
[ ] Czy mogę wykonać te operacje przed lub po spotkaniu?
[ ] Czy mikrofon ma hardware mute?

W trakcie spotkania:

[ ] Nie wpisuję sekretów przy aktywnym mikrofonie.
[ ] Mutuję mikrofon przed logowaniem.
[ ] Nie trzymam telefonu obok klawiatury przy pracy z sekretami.
[ ] Nie pokazuję terminala z komendami zawierającymi sekrety.
[ ] Nie dyktuję tokenów ani kodów.

Po spotkaniu:

[ ] Czy nagranie zawiera wrażliwe operacje?
[ ] Czy nagranie ma ograniczony dostęp?
[ ] Czy retencja nagrania jest uzasadniona?
[ ] Czy transkrypcja lub AI summary nie utrwaliły danych wrażliwych?

Checklista dla administratorów i SOC

Endpointy:

[ ] Lista aplikacji z dostępem do mikrofonu jest znana.
[ ] Mikrofon jest zablokowany na PAW/SAW, jeśli nie jest potrzebny.
[ ] Teams/Zoom/Meet nie działają na stacjach privileged.
[ ] EDR/MDM raportuje nietypowe użycie mikrofonu.
[ ] Użytkownik widzi stan mikrofonu i ma łatwy hardware mute.

Tożsamość:

[ ] Krytyczne systemy używają phishing-resistant MFA.
[ ] Wdrożono WebAuthn/FIDO2 tam, gdzie to możliwe.
[ ] Break-glass accounts mają osobne procedury.
[ ] Hasła produkcyjne nie są ręcznie wpisywane podczas spotkań.
[ ] PAM brokeruje dostęp i ogranicza ekspozycję sekretów.

Wideokonferencje:

[ ] Nagrywanie spotkań technicznych wymaga świadomej decyzji.
[ ] Retencja nagrań jest ograniczona.
[ ] Dostęp zewnętrznych uczestników do nagrań jest kontrolowany.
[ ] AI transcription/summarization jest objęte klasyfikacją danych.
[ ] Incident bridge ma procedurę "no secrets on open mic".

Physical security:

[ ] Sale wysokiej poufności mają zasady dla telefonów.
[ ] Mikrofony konferencyjne są zinwentaryzowane.
[ ] Urządzenia prywatne nie trafiają do stref wysokiego ryzyka.
[ ] Dystans, ekranowanie i kontrola przewodów są rozważane tam, gdzie ryzyko to uzasadnia.
[ ] Threat model obejmuje sensory, nie tylko sieć.

Checklista dla GRC i architektów bezpieczeństwa

Polityki:

[ ] Czy secure workspace policy mówi o mikrofonach?
[ ] Czy polityka spotkań mówi o wpisywaniu sekretów?
[ ] Czy nagrania spotkań są sklasyfikowane jako potencjalnie wrażliwe?
[ ] Czy procedury IR zabraniają wpisywania break-glass credentials na aktywnym callu?
[ ] Czy model ryzyka obejmuje side-channel attacks?

Ryzyko dostawców:

[ ] Czy dostawca wideokonferencji przetwarza audio do AI summary?
[ ] Gdzie trafiają nagrania?
[ ] Kto ma dostęp administracyjny do nagrań?
[ ] Jak długo są przechowywane?
[ ] Czy można wyłączyć transkrypcję dla spotkań wysokiego ryzyka?

Architektura:

[ ] Czy istnieje rozdział urządzeń do komunikacji i administracji?
[ ] Czy PAW ma minimalny zestaw aplikacji?
[ ] Czy produkcyjne sekrety są w ogóle znane człowiekowi?
[ ] Czy logowanie do systemów krytycznych wymaga wpisywania sekretów?
[ ] Czy można zastąpić hasła passkeys, certyfikatami, PAM albo krótkotrwałymi tokenami?

Co z producentami sprzętu?

To jest część tematu, która może wrócić mocniej w najbliższych latach.

Do tej pory elektronika konsumencka była projektowana głównie pod:

wydajność,
koszt,
czas pracy na baterii,
wygodę,
kompatybilność,
estetykę,
minimalne wymagania EMC,
bezpieczeństwo software’u.

Rzadziej pod:

minimalizację kompromitujących emanacji,
testy side-channel,
akustyczną jednorodność klawiatury,
kontrolę sygnałów z mikrofonów,
hardening sensorów,
EMSEC dla urządzeń konsumenckich.

Wyden i Brown w liście do GAO pytają między innymi o wykonalność i koszt dodawania countermeasures do elektroniki konsumenckiej oraz o potencjalne opcje polityczne, w tym wymagania wobec producentów.

Nie spodziewałbym się szybkiego „TEMPEST compliance for laptops” dla zwykłych użytkowników. Ale presja może pojawić się w segmentach:

government,
defense,
critical infrastructure,
executive devices,
secure communications,
high-assurance endpoints,
privacy-focused hardware,
R&D environments.

Możemy też zobaczyć bardziej przyziemne mechanizmy:

lepsze hardware mute,
jawna telemetria aktywności mikrofonu,
silniejsze permission boundaries dla audio,
tryby "secure meeting",
tryby "privileged operation" blokujące sensory,
MDM policies dla sensorów,
lepsza klasyfikacja nagrań,
osobne certyfikacje dla urządzeń high-security.

To jest naturalna ewolucja. Najpierw ignorujemy klasę ryzyka, potem pojawiają się PoC, potem incydenty albo presja polityczna, potem vendorzy robią opcjonalne funkcje, a dopiero później standardy.

Największy błąd: traktować to jako problem haseł

Tytuł mówi o hasłach, bo hasła są chwytliwe. Ale problem jest szerszy.

Klawiatura zdradza nie tylko hasła.

Może zdradzać:

komendy administracyjne,
nazwy hostów,
nazwy klientów,
ścieżki do plików,
fragmenty kodu,
numery spraw,
dane osobowe,
query do bazy,
wzorce pracy,
tempo reakcji,
momenty logowania,
nazwy systemów,
strukturę środowiska.

Jeżeli atakujący nie odzyska hasła, ale dowie się, że zespół ma hosty:

bastion-prod-eu
vault-dr
postgres-finance
aks-legacy

to też jest wartość.

Side-channel może być rozpoznaniem. Nie musi od razu kończyć się kompromitacją.

Największy błąd drugi: traktować to jako problem mikrofonu

Mikrofon jest tylko jednym sensorem.

Dzisiaj mówimy o acoustic keystroke recovery, ale ta sama klasa problemów obejmuje:

EM emanations z klawiatur,
EM emanations z ekranów,
emanacje z kabli HDMI/DVI/VGA,
odbicia optyczne ekranu,
wibracje mierzone akcelerometrem,
termiczne ślady na klawiszach,
dźwięk drukarek,
dźwięk wentylatorów,
migotanie LED,
pobór mocy,
czas odpowiedzi,
cache timing,
RF leakage.

CRS opisuje przykłady akustyczne, radiowe i elektromagnetyczne jako sposoby obserwacji emanacji z urządzeń, które mogą następnie być analizowane i rekonstruowane do postaci ujawniającej dane wrażliwe.

Dlatego dobra rekomendacja nie brzmi:

zaklej mikrofon

Tylko:

dodaj sensory i emanacje do threat modelu.

Największy błąd trzeci: wierzyć, że „air-gapped” znaczy „niewidzialny”

Air-gap ogranicza klasyczne kanały sieciowe. Nie wyłącza fizyki.

System odizolowany od sieci nadal:

świeci,
brzęczy,
drga,
pobiera prąd,
emituje ciepło,
generuje pole elektromagnetyczne,
ma ekran,
ma klawiaturę,
ma przewody,
ma operatora.

Air-gap jest kontrolą. Nie magiczną barierą.

TEMPEST, EMSEC i side-channel attacks od lat przypominają, że „nie ma kabla sieciowego” nie oznacza „nie ma kanału”.

Co publikować, a czego nie publikować

Dla SecurityBezTabu.pl ten temat jest świetny, ale trzeba uważać na formę.

Nie robiłbym artykułu jako pełnego ofensywnego tutoriala:

jak zebrać etykietowany dataset,
jak zbudować klasyfikator,
jak trenować model,
jak odtwarzać hasła,
jak poprawiać wyniki LLM-em.

To byłoby technicznie ciekawe, ale redakcyjnie mniej wartościowe i bardziej ryzykowne.

Lepszy kierunek to:

wyjaśnić mechanizm,
pokazać historię od TEMPEST do AI,
zbudować realistyczny threat model,
opisać ograniczenia,
dać defensywne komendy,
dać checklistę dla SOC/GRC/adminów,
pokazać bezpieczny spektrogram,
zakończyć rekomendacjami.

Taki tekst jest evergreen. Nie zestarzeje się po miesiącu, bo nie jest tylko o jednym PoC. Jest o klasie problemów.

Dlaczego to ma znaczenie

Bo branża cyberbezpieczeństwa ma tendencję do patrzenia tam, gdzie ma logi.

Patrzymy w SIEM.
Patrzymy w EDR.
Patrzymy w IAM.
Patrzymy w cloud audit logs.
Patrzymy w proxy.
Patrzymy w CASB.
Patrzymy w Kubernetes events.
Patrzymy w GitHub audit log.

A side-channel mówi: sekret może wyciec obok logów.

Nie przez POST /api/secrets.
Nie przez scp.
Nie przez malware dumping LSASS.
Nie przez phishing link.

Tylko przez dźwięk klawiatury na nagraniu spotkania.

To nie znaczy, że mamy porzucić klasyczne kontrole. To znaczy, że dla wysokowartościowych środowisk musimy dodać warstwę fizyczną i operacyjną.

Rekomendacje są konkretne:

1. Nie wpisuj sekretów przy aktywnym mikrofonie.
2. Nie prowadź calli na PAW.
3. Ogranicz ręczne wpisywanie haseł.
4. Wdrażaj passkeys/FIDO2/WebAuthn/PAM.
5. Traktuj nagrania spotkań jako potencjalnie wrażliwe.
6. Kontroluj mikrofony i sensory w strefach wysokiego ryzyka.
7. Uwzględnij TEMPEST/EMSEC tylko tam, gdzie ryzyko to uzasadnia.
8. Edukuj administratorów: mute przed sekretem to nie kultura spotkania, to kontrola bezpieczeństwa.

Techniczne CTA

Sprawdź to w swojej organizacji:

[ ] Czy administratorzy wpisują hasła podczas spotkań?
[ ] Czy PAW ma Teams/Zoom/Slack/Discord?
[ ] Czy spotkania incident response są nagrywane?
[ ] Czy nagrania mają retencję krótszą niż reszta dokumentów?
[ ] Czy MDM wie, które aplikacje mają mikrofon?
[ ] Czy EDR potrafi wykryć audio capture na stacji privileged?
[ ] Czy polityka secure workspace mówi o telefonach na biurku?
[ ] Czy break-glass procedure zawiera krok "no active microphone"?

Przetestuj na stagingu procedurę:

mute -> logowanie -> operacja -> unmute

Przejrzyj uprawnienia mikrofonu na laptopach administracyjnych.

Usuń aplikacje konferencyjne z PAW.

Włącz passkeys tam, gdzie użytkownik dzisiaj wpisuje hasło ręcznie.

Przeklasyfikuj nagrania spotkań technicznych.

I najważniejsze: przestań traktować mikrofon jak neutralny dodatek do laptopa.

To sensor. A każdy sensor w security jest pytaniem o threat model.

Podsumowanie

Acoustic Keystroke Recovery nie jest magiczną nowością zrobioną przez AI. To kolejna odsłona starej prawdy: komputer zdradza więcej, niż pokazują logi.

Kiedyś problemem były elektromagnetyczne emanacje z monitorów, przewodów i klawiatur. Później VoIP pokazał, że rozmowy głosowe mogą nieść dźwięki klawiszy. Dziś deep learning i LLM-y poprawiają klasyfikację, odporność na hałas i korektę sekwencji. Jutro podobne podejścia będą łączone z obrazem, RF, akcelerometrami i innymi sensorami.

Nie trzeba panikować.

Trzeba dodać jedną kategorię do myślenia:

Czy sekret może wyciec przez fizyczny efekt uboczny?

W środowiskach niskiego ryzyka odpowiedź będzie często: „mało prawdopodobne, akceptujemy”.

W środowiskach wysokiego ryzyka odpowiedź powinna brzmieć:

nie wpisujemy sekretów przy aktywnym mikrofonie,
nie łączymy calli z privileged access,
nie traktujemy nagrań spotkań jak neutralnych plików,
nie udajemy, że sensory nie istnieją.

Najlepsza puenta jest prosta:

Kiedyś podsłuchiwano fale z kabli i ekranów. Dziś można analizować dźwięk klawiatury z mikrofonu laptopa. Technologia się zmieniła. Zasada została ta sama: sekret może wyciec tam, gdzie nikt nie patrzy w logi.

Bibliografia

• https://pwn.guide/free/hardware/keystroke-recovery
• https://research.ibm.com/publications/keyboard-acoustic-emanations
• https://www.cs.cornell.edu/~shmat/courses/cs6431/zhuang.pdf
• https://arxiv.org/abs/1609.09359
• https://arxiv.org/abs/2308.01074
• https://www.usenix.org/system/files/woot25-ayati.pdf
• https://arxiv.org/abs/2605.03384
• https://infoscience.epfl.ch/entities/publication/0e476a8a-19a3-4b7d-af09-1c681c3320e8
• https://csrc.nist.gov/glossary/term/TEMPEST
• https://www.wyden.senate.gov/imo/media/doc/wyden_gao_tempest_letter.pdf
• https://csrc.nist.gov/glossary/term/compromising_emanations
• https://csrc.nist.gov/glossary/term/emission_security
• https://csrc.nist.gov/glossary/term/red_black_concept