Permanentna inwigilacja w praktyce

NoahWatson

Well-Known Member
1 297
3 200
No dobra, niech nawet hasło będzie kurwa ważyć 47 bitów.
Czy to jest dziś problem?
Przecież w takiej sytuacji wystarczy zrzut pamięci do laptopa, wysyłka do chmury i max. po godzinie mamy PIN.
iPhone usuwa (albo usuwał we wcześniejszych wersjach - nie jestem na bieżąco) po 10 nieudanych próbach permanentnie klucz potrzebny do rozszyfrowania i szyfrowania danych. Nie zrzucisz klucza od tak, bo jest zabezpieczony sprzętowo.
 

NoahWatson

Well-Known Member
1 297
3 200
https://www.nytimes.com/2019/08/13/opinion/health-data.html
I initially got on the phone with Sobhani to get a sense of how our medical devices might be compromised. But the discussion quickly veered into different territory. She argued that our focus on medical data as the information coming out of connected pacemakers isn’t nearly as vulnerable as the information coming from far less secure sources. There’s a bigger security risk here, she argued, saying “all our data is health data.”

What Sobhani is talking about is a relatively new field called digital phenotyping, which was coined at the Harvard T.H. Chan School of Public Health. It means taking information from our digital behaviors — on websites, via our phones — and using it to gain insight into potential health issues. “People don’t realize that small data points monitored continuously can be very predictive of behaviors and health and that’s why I’m worried,” Sobhani said. She noted research that suggests early Parkinson’s motor issues might be more accurately detected by typing patterns on keyboards. And she mentioned one initial study tying language in social media posts and Facebook likes that accurately predicted depressive episodes.

Social media companies and marketers use this kind of metadata as a way to predict our behaviors all the time; for example, using shopping behaviors, companies often try to gauge whether someone is pregnant. It only makes sense that as technology encroaches deeper into our lives and data analysis gets better, more brazen researchers and organizations would try to glean insights. In such a world, Sobhani argues, even some of our most trivial data — the way our eyes move in a video clip — could be thought of as health data.
 

kr2y510

konfederata targowicki
12 770
24 700
iPhone usuwa (albo usuwał we wcześniejszych wersjach - nie jestem na bieżąco) po 10 nieudanych próbach permanentnie klucz potrzebny do rozszyfrowania i szyfrowania danych.
To nie ma znaczenia.
Haseł (w tym PIN-ów) się nie łamie poprzez ich wprowadzanie. Wpierw robi się kopię pamięci w fonie (to jest jeden chip lub dwa chipy) i dopiero na tych danych się działa. Nie wiem jak jest dokładnie z iPhonami, ale zawsze na płytce są miejsca do przyłączenia interfejsu jTAG lub jakiegoś innego, przez który się można dobrać pośrednio do pamięci.
 

NoahWatson

Well-Known Member
1 297
3 200
To nie ma znaczenia.
Haseł (w tym PIN-ów) się nie łamie poprzez ich wprowadzanie. Wpierw robi się kopię pamięci w fonie (to jest jeden chip lub dwa chipy) i dopiero na tych danych się działa. Nie wiem jak jest dokładnie z iPhonami, ale zawsze na płytce są miejsca do przyłączenia interfejsu jTAG lub jakiegoś innego, przez który się można dobrać pośrednio do pamięci.
The device’s unique IDs (UIDs) and group IDs (GIDs) are AES-256 bit keys
fused (UID) or compiled (GID) into the application processor and Secure
Enclave during manufacturing. No software or firmware can read them directly;
they can see only the results of encryption or decryption operations performed
by dedicated AES engines implemented in silicon using the UID or GID as a key.
The application processor and Secure Enclave each have their own UID and
GID. The Secure Enclave UID and GID can only be used by the AES engine
dedicated to the Secure Enclave. The UIDs and GIDs are also not available
through Joint Test Action Group (JTAG) or other debugging interfaces.
https://www.apple.com/business/docs/site/iOS_Security_Guide.pdf

Oprócz tego limit prób (ale on chyba jest software'owy):
https://support.apple.com/pl-pl/guide/iphone/iph14a867ae/ios
Wymazywanie danych po 10 nieudanych próbach podania kodu blokady

Możesz określić, że po 10 nieudanych próbach podania kodu blokady wszystkie dane, multimedia i ustawienia iPhone'a mają zostać wymazane.

Przejdź do Ustawień i wykonaj jedną z następujących czynności:
1. iPhone X i nowsze: Stuknij w Face ID i kod.
Inne modele: Stuknij w Touch ID i kod.
2. Włącz Wymaż dane.

Nie twierdzę, że nie ma w najnowszych iPhonach przypadkowych dziur lub backdoorów, które pozwalają obejść niektóre zabezpieczenia np limit nieudanych prób wprowadzeniach hasła, ale to już inna kwestia.
 

kr2y510

konfederata targowicki
12 770
24 700
@NoahWatson Dzięki za podlinkowny dokument.
Ale tu nie chodzi ani dziury, ani backdoory. W każdym smartfonie jest pamięć Flash i to z niej się zrzuca zawartość, a nie robi się tego przez OS. No chyba że OS to umożliwia. Do złamania hasła/PIN-u wystarczy ściągnąć jeden sektor z nagłówkiem i ze dwa sektory z typową zawartością dla kontroli. Jeden sektor ma zazwyczaj 8kB + kod korekcyjny. I na tych danych się łamie hasło/PIN.
Apple zabezpieczyło iPhony przed prostymi metodami dostępu, a nie przed dostępem do hardware z pominięciem OS-u.

I jeszcze jedno. Z dokumentu wynika, że szyfrowana jest jedynie przestrzeń użytkownika, a nie cały OS bez bootloadera, jak to powinno być zrobione profesjonalnie. Z dokumentu wynika też, że schemat szyfrowania jest dość prosty i typowy. Gdyby było inaczej, to firma by tego tak szybko nie złamała.
 

NoahWatson

Well-Known Member
1 297
3 200
@NoahWatson Dzięki za podlinkowny dokument.
Ale tu nie chodzi ani dziury, ani backdoory. W każdym smartfonie jest pamięć Flash i to z niej się zrzuca zawartość, a nie robi się tego przez OS. No chyba że OS to umożliwia. Do złamania hasła/PIN-u wystarczy ściągnąć jeden sektor z nagłówkiem i ze dwa sektory z typową zawartością dla kontroli. Jeden sektor ma zazwyczaj 8kB + kod korekcyjny. I na tych danych się łamie hasło/PIN.
Apple zabezpieczyło iPhony przed prostymi metodami dostępu, a nie przed dostępem do hardware z pominięciem OS-u.
Apple zabezpieczyło iPhony przed dostępem do hardware. Jest kilka kluczy. Klucz pozwalający rozpocząć rozszyfrowywanie systemu pliku nie znajduje się w pamięci Flash, tylko w procesorze.
 

raiden00

megazord
160
278
@kr2y510 właśnie chyba chodzi o to, że Apple się zabezpieczyło przed bezpośrednim zrzutem z FLASH, tak żeby dostęp do RAW danych był utrudniony. Ale...
Fizycznie pamięć FLASH ciągle gdzieś musi być, więc nic nie stoi na przeszkodzie żeby zdjąć z chipa obudowę (decapping) i działać bezpośrednio na strukturze krzemowej. Znalezienie pamięci w takiej kostce krzemu nie jest żadnym problemem. Dalej możemy kombinować z analizą optyczną (zapisany bit inaczej odbija światło niż 0) albo podpiąć się elektrycznie po wcześniejszej analizie wstecznej. Mając odpowiednie laboratorium, kumatych ludzi i duży budżet jest to jak najbardziej możliwe.
 

kr2y510

konfederata targowicki
12 770
24 700
Apple zabezpieczyło iPhony przed dostępem do hardware.
Niezbyt skutecznie jak widać.
właśnie chyba chodzi o to, że Apple się zabezpieczyło przed bezpośrednim zrzutem z FLASH, tak żeby dostęp do RAW danych był utrudniony. Ale...
To nie tak.

Spójrzcie na to z punktu widzenia Apple.
- Jak wprowadzą zbyt mocne zabezpieczenia, nie będą mogli tego eksportować na cały świat, bo w USA są ograniczenia eksportowe technologii szyfrujących (dawniej to było 40-bitów).
- Jak wprowadzą zbyt słabe zabezpieczenia, to też są w dupie, bo nie będą mogli sprzedawać tego sprzętu dla rządu USA.

Więc Apple zrobiło tak, że można złamać ich zabezpieczenia, ale koszty wejścia na ten rynek są wysokie. Tak by firm łamiących te zabezpieczenia nie było zbyt dużo, bo jak jest ich dużo, to nikt tego nie będzie w stanie kontrolować. I tak to się kręci.

Jest kilka kluczy. Klucz pozwalający rozpocząć rozszyfrowywanie systemu pliku nie znajduje się w pamięci Flash, tylko w procesorze.
To nie do końca tak.
Bo by sprzedawać urządzenia dla np. żołnierzy USA, to urządzenia muszą spełniać schematy szyfrowania zgodne z normami NIST. I oczywiście spełniają. A to oznacza, że klucze wewnętrzne są przehashowywane z PIN-em według normy NIST i jest możliwość dobrania się do nich przez sprzęt. Błędne koło. By się do tego dobrać, potrzebne są duże koszta wejścia, co jest w stanie spełnić przeliczalna (ważne!) ilość firm.

Fizycznie pamięć FLASH ciągle gdzieś musi być, więc nic nie stoi na przeszkodzie żeby zdjąć z chipa obudowę (decapping) i działać bezpośrednio na strukturze krzemowej.
To nie tak. Dużych pamięci flash nie ładuje się do procków, one są na zewnątrz. By czytać dane najprościej wystarczy je wylutować (potem przylutować), ale potrzeba znać jeszcze jedną rzecz, jaką jest schemat kodu korekcyjno-detekcyjnego użytego do zakodowania na nich danych. A dziś to już nie są proste kody wielomianowe dokładane do danych jak dawniej, co wynika z faktu, że dziś w pamięciach flash w jednej komórce jest kilka bitów (komórka pamięci może przechowywać wiele poziomów napięć).
 

raiden00

megazord
160
278
To nie tak. Dużych pamięci flash nie ładuje się do procków, one są na zewnątrz.
Bardziej chodziło mi o przypadek gdy chip pamięci jest zintegrowany z silnikiem kryptograficznym i bez autoryzacji nie odczytasz danych. Od lat coś takiego jest na rynku dla pamięci o małej pojemności (np. CryptoMemory od Atmel), myślałem że iphony mają coś podobnego. Teraz widzę, że ich krypto i NAND to oddzielne układy.

A dziś to już nie są proste kody wielomianowe dokładane do danych jak dawniej, co wynika z faktu, że dziś w pamięciach flash w jednej komórce jest kilka bitów (komórka pamięci może przechowywać wiele poziomów napięć).

Wystarczy znaleźć dokumentację pamięci i mamy wszystkie potrzebne informacje aby zrobić zrzut z NAND. Po krótkich poszukiwaniach widzę, że Apple używa normalnie dostępnych pamięci od samsunga/toshiby więc to żaden problem. Poza tym interfejs dostępu do pamięci jest mocno standaryzowany, tak samo jak wyprowadzenia z chipów. Głownie dlatego, że rynek pamięci jest mocno dynamiczny i dążono do pełnej kompatybilności między producentami.
Swego czasu robiłem dump NAND z chińskiego drona przez bootloader procka do którego udało mi się dostać. Kilka godzin printowania hexów, skrypt w pythonie i cały system plików mój xD
 

kr2y510

konfederata targowicki
12 770
24 700
Apple używa normalnie dostępnych pamięci od samsunga/toshiby więc to żaden problem. Poza tym interfejs dostępu do pamięci jest mocno standaryzowany
Ależ tak, ale ja nie o tym.
Bo o ile interfejs (a nawet wyprowadzenia końcówek) jest standardowy, to kod korekcyjno-detekcyjny już nie, tym bardziej jak się robi własne chipy jak Apple. Zrzut fizycznego obrazu pamięci nie jest tożsamy z komendą dd w Linuksie. Trzeba go jeszcze po drodze przetworzyć.
 

raiden00

megazord
160
278
@kr2y510 Pisząc 'kod korekcyjno-detekcyjny' nie wiem czy masz na myśli ECC czy coś innego?
Jeśli tak to ECC służy tylko do detekcji błędów i ewentualnej naprawy błędnych bitów.
Możesz przeczytać strony pamięci NAND z danymi ignorując całkowicie ECC.
 

kr2y510

konfederata targowicki
12 770
24 700
@kr2y510 Pisząc 'kod korekcyjno-detekcyjny' nie wiem czy masz na myśli ECC czy coś innego?
Jeśli tak to ECC służy tylko do detekcji błędów i ewentualnej naprawy błędnych bitów.
Możesz przeczytać strony pamięci NAND z danymi ignorując całkowicie ECC.
Tak i nie.
Bo kiedyś (i jeszcze dziś w starszych rozwiązaniach) było tak, że kod korekcyjny był dodawany do normalnych danych, czyli w pamięci były dane i ECC. Wystarczyło wywalić ECC i otrzymywało się dane bez korekcji błędu. Oczywiście lepiej przetworzyć i dane i ECC by dane były spójne, bo im większe pamięci, tym więcej błędów (praktycznie należy założyć, że błędy są zawsze, bo żaden producent nie jest w stanie dokładnie przetestować pamięci flash).
Dziś jest inaczej. Dziś dane są tak kodowane, by zawierały w sobie ECC. Jest tak dlatego, by uzyskać wagę kodu w okolicy 50%, bo wtedy jest najmniej błędów. W przypadku najnowszych (technologicznie - czyli cztery bity na jedną komórkę pamięci = 16 poziomów napięcia) pamięci Samsunga zapis wygląda tak:
- dane są kodowane i zawierają kod korekcyjny
- następuje zapis
- następuje odczyt tych danych
- w danych odczytanych są błędy i następuje przekodowanie
- następuje ponowny zapis danych
Czyli mamy trzy cykle do zapisania danych (zapis, odczyt, zapis). Odczyt jest normalny w jednym cyklu. Schemat kodowania rekomendowany przez Samsunga jest jawny.
Więc wszystko zależy od typów zastosowanych pamięci i od tego czy producent chipu (tu Apple) nie wprowadził własnego kodowania. W najgorszym przypadku zaszyfowania danych, do odczytu kostek należałoby użyć innego iPhona (ten sam model procesora) ze znanym PIN-em.
 

kompowiec

freetard
2 567
2 622
@kompowiec jak ktoś mi zapłaci to czemu nie :p
Tak w temacie dekoderów
Jedna z najlepszych prezentacji odnośnie hackowania hardware jaką widziałem. Jest nawet decapping i czytanie ROMu ze zdjęcia :)

ta kojarze, ktoś już mi ten wykład podrzucał na ircu. Powiem tak, fajne ale nie chciałoby mi się z tym tak jebać.

No i niemiecki, masakra (mówie o innych filmach)
 

raiden00

megazord
160
278
Dziś jest inaczej. Dziś dane są tak kodowane, by zawierały w sobie ECC.

No nie, pamięć NAND jest zorganizowana tak, że masz dane i za danymi oddzielnie tzw. "spare area" w której siedzi ECC.
Celem ECC jest dostarczenie redundancji do danych, czyli dwa oddzielne obszary w pamięci, które przetrzymują informację o danych. Pierwszy zapisane dane i drugi ECC, który zawiera jedynie informację o poprawności. Nie wiem o czym piszesz, ale raczej nie jest to ECC.
Jak masz jakieś źródła to z chęcią przygarnę :)

Obsługa NAND zawsze wygląda tak samo, nie ważne czy to jest SLC, MLC, TLC czy QLC. Jakieś dodatkowe kodowanie możesz wprowadzać na wyższym poziomie, ale mowa była o odczycie RAW danych z FLASH. Można zajrzeć do źródeł pierwszego lepszego otwartego OS i przekonać się jak to jest robione.
EDIT: chyba że mowa o jakiś serio nowych technologiach, których open-sourcowe projekty nie wspierają. To wtedy chylę czoła.

No i niemiecki, masakra (mówie o innych filmach)
Niemiecki jak niemieck. Gorzej się robi jak pomyślisz ile komuchów ściąga każdego roku na CCC :(
 

kr2y510

konfederata targowicki
12 770
24 700
No nie, pamięć NAND jest zorganizowana tak, że masz dane i za danymi oddzielnie tzw. "spare area" w której siedzi ECC.
Tzw. spare area, to obszar zdefiniowany przez OS (lub jakiś inny soft), a nie producenta pamięci. Dziś większość pamięci ma tzw. ECC Engine, z którego możesz korzystać lub nie. Większość producentów pendrive-ów, modułów Flash itp. stosuje własne (ściśle strzeżone) algorytmy korekcji błędów.

Celem ECC jest dostarczenie redundancji do danych, czyli dwa oddzielne obszary w pamięci, które przetrzymują informację o danych.
Nie tak. Samo ECC jest wyliczane z danych i trzymane osobno. Z danych masz dane bez korekcji, a z ECC bez danych nie masz nic.

Można zajrzeć do źródeł pierwszego lepszego otwartego OS i przekonać się jak to jest robione.
I jest zazwyczaj robione hujowo. ;)

nowych technologiach, których open-sourcowe projekty nie wspierają.
Nie żadnych nowych technologiach, bo to technologie sprzed 10-lat. Po prostu ujawnienie tej wiedzy spowodowałoby przekazanie jej konkurencji. Stąd wszystkie zamknięte i masowe rozwiązania mają to schowane w procesorze, bo wtedy zwiększa się szybkość zapisu i odczytu z pamięci (nie marnuje się czasu na wyliczanie ECC przez kostkę pamięci).
Akurat gadasz z człowiekiem, który przez 11-lat do 2002r. projektował moduły pamięci (PCB, program do maszyny nakładającej, pastę (dla małych serii tak się robi) i chipy, testy itd.), wprawdzie RAM ale o pamięciach flash i zewnętrznym ECC też wiem trochę.

Polecam Tobie wykonanie prostego i niezbyt czasochłonnego eksperymentu. Znajdź jakiś stary prehistoryczny pendrive o pojemności 64MB/128MB/256MB. One wtedy nie miały ECC. I zapisz na niego jak największy plik zawierający same zera i od 0.01 do 0.1% procent jedynek znakami mającymi binarnie jedną jedynkę w sobie (np. @ = 10000000 czy spacja = 01000000). Zachowaj plik na dysku i porównaj zawartość plików po 2 tygodniach - ile one mają błędów. Po czym zrób to samo z jakimś plikiem typu Zip.
 
Ostatnia edycja:

raiden00

megazord
160
278
Tzw. spare area, to obszar zdefiniowany przez OS (lub jakiś inny soft), a nie producenta pamięci.
Zgadza się, ale ciągle są to dane i dopiero za nimi spare area. Dane oddzielone od ECC. Nie ważne czy masz implementacje w software, w hardware czy w krzemie pamięci. Ciągle możesz odczytać dane.

Nie tak. Samo ECC jest wyliczane z danych i trzymane osobno. Z danych masz dane bez korekcji, a z ECC bez danych nie masz nic.
No właśnie to napisałem. Dwa oddzielne obszary w których jest trzymana informacja o danych, nie same dane. ECC to informacja o danych pozwalająca tylko zweryfikować poprawność i ewentualnie naprawić dane właściwe.

Akurat gadasz z człowiekiem, który przez 11-lat do 2002r. projektował moduły pamięci

Ja akurat trochę siedzę w reverse engineering systemów embedded i trochę więcej w programowaniu niskopoziomowym, więc też coś tam działałem z pamięciami i ich obsługą.

Polecam Tobie wykonanie prostego i niezbyt czasochłonnego eksperymentu.
Niestety ale znalezienie starego pendriva wydaje się nie realne w tej chwili, a szkoda bo z chęcią bym zobaczył jakie kości w nim siedzą ;)
 

kr2y510

konfederata targowicki
12 770
24 700
znalezienie starego pendriva wydaje się nie realne w tej chwili, a szkoda bo z chęcią bym zobaczył jakie kości w nim siedzą ;)
Na 90% tzw. zwalasy. Czyli kości o pojemności 2 razy większej niż naprawdę potrzeba, ale ze zwaloną połówką pamięci. Wykorzystywana jest ta "dobra" połówka. Odpady trzeba jakoś zagospodarować.
 
Do góry Bottom