Szerinted az Apple végül enged a kormányzati nyomásnak és elkészíti az FBiOS-t, vagy kitart és nem készít backdooros iOS-t?

Titkosítás, biztonság, privát szféra

Kitart.
13% (42 szavazat)
Végül enged, mert nem tehet mást. De elmegy a végsőkig.
21% (69 szavazat)
Enged, mert ez az egész csak színjáték a részéről.
52% (167 szavazat)
Egyéb, leírom.
3% (11 szavazat)
Csak az eredmény érdekel.
10% (33 szavazat)
Összes szavazat: 322

( trey | 2016. 02. 20., szo – 10:35 )

A szavazás apropója, hogy folytatódik az ügy, az amerikai igazságügyi minisztérium, a DOJ pénteken beadványt nyújtott be annak érdekében, hogy rászorítsa az Apple-t, hogy az tegyen eleget a bírósági rendelkezésnek és unlockolja a San Bernardino-i terrortámadás kapcsán lefoglalt iPhone-t. A DOJ szerint az Apple visszautasítása csak marketing stratégia, nem egyéb.

A részletek itt olvashatók.

--
trey @ gépház

( anr | 2016. 02. 20., szo – 10:53 )

elkésziti, titokban át is adja, de nyilvanosan mindent tagadni fog
az FBI meg azt hazudja, hogy mashonnan tudta meg azokat az infokat, amiket a telefonrol leszedett

az FBI szamara is fontos, hogy a bunozok azt gondoljak, hogy az iphone-on biztonsagosan tarolhatnak illegalis dolgokat

--
Live free, or I f'ing kill you.

Majd szólnak Mcafee-nak, aztán ő majd jól megoldja :D
http://hothardware.com/news/john-mcafee-offers-to-decrypt-san-bernardin…
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

A helyzet egy kicsit bonyolultabb ennél.

Ha jól rakom össze, akkor a következő történt:
1. Begyűjtötték a tárgyi bizonyítékokat
2. Kértek a bíróságtól engedélyt, hogy hozzáférhessenek a telefon tartalmához. Ez valószínűleg egy közönséges search warrant (kb házkutatási engedélynek megfelelő) kérés volt, ami egy alapvetően gyors rutineljárás. Itt nincs hosszadalmas tárgyalás, meghallgatás, szakértők, a bíróság a technikai részletek kifejtése nélkül hozza meg a döntést.
3. Ennek birtokában valaki a San Bernardino megyei ügyészségen vagy a seriff hivatalban (ez nem teljesen egyértelmű az infókból) megváltoztatta a gyanúsítottak iCloud account jelszavát. Tehát nem a telefonon változtattak jelszót. link. Ehhez nyilván az Apple segítséget kellett nyújtson. Valószínűleg rutineljárás, hogy esetleg szabadon levő elkövetők az accounton levő esetleges bizonyítékokat ne piszkálhassák.
4. Később, ezúttal már az FBI, fordult az Apple-höz. Hozzáférést kértek a telefon tartalmához. Az Apple egyáltalán nem volt elutasító, sőt kifejezetten segítőkész volt. Mindent megtettek, amit szerver oldalon lehetséges, valamint adtak a módszert arra, hogy hogyan lehet a telefon tartalmát megszerezni.
Olyan Wifi AP közelébe kell vinni, amire a telefon egyszer már csatlakozott (autoconnect legyen), majd bevárni a napi iCloud sync-et, vagy ha lehet szerver oldalról forszírozni azt. Ezzel a telefon tartalmáról lesz egy friss backup az iCloudon. Majd iCloud-on jelszót váltani (hogy ismert legyen), és egy tiszta iPhone-ra visszsync-elni. Ezzel a telefont ugyan nem törték fel, de a tartalma megvan. link
5. Az FBI szomorúan tapasztalta, hogy a módszer nem működik, mert az iCloud jelszót a helyi hatóságok már jóval korábban megváltoztatták és a telefon már nem autentikál a szerverrel. Ezzel gyakorlatilag elcseszték a backdoor lehetőséget.
6. Visszamentek az Apple-höz, hogy "elkúrtuk", most kérjük a B-tervet. Az Apple pedig azt mondta, hogy nincs B terv, ez volt A Backdoor. Nyilván jöttek az ötletek, hogy az Apple találjon/csináljon/fejlesszen/varázsoljon valahonnan egy 0-day exploitot a telefonon a disk encryption ellen. Vagy csináljon egy hibás iOS build-et és OTA upgrade-del tolja rá a telefonra stb. Na ez az, amibe az Apple nem ment bele. Technikailag sem biztos, hogy kivitelezhető (úgy hogy közben a telefonon az adatok garantáltan ne vesszenek el - ha nem sikerül az Apple-t bizonyíték megsemmisítéséért veszik elő). Az is biztos, hogy költséges és időigényes fejlesztés lenne. Valamint jogilag sem biztos, hogy az Apple egyáltalán kötelezhető ilyesmire link, ez ugyanis bőven túlmutat törvényben előírtakon.
7. Innentől az FBI elkezdte fenyegetni őket, nyilvánosan azt kommunikálni, hogy akadályozzák az igazságszolgáltatást és hivatkozni a bírósági végzésre. De az a bírósági végzés minden bizonnyal a fenti részletek kifejtése nélkül született és nem biztos, hogy egy bíróság ténylegesen kötelezné az Apple-t arra, amit az FBI konkrétan kér tőle.
8. Emiatt az Apple panasszal élt, ez itt olvasható, az EXHIBIT1 alatt: link
9. A fenti link többi része pedig az FBI beadványa, hogy mégis kötelezzék az Apple-t a kérésük teljesítésére. Indoklásként pedig arra hivatkoznak, hogy az Apple-által elkészített eszközöket "csak erre az egy esetre használnák" becsszóra.

---
Régóta vágyok én, az androidok mezonkincsére már!

Lássuk be azért, hogy a történet több sebből vérzik... Egyrészt miért ne tudná kérésre visszaállítani az Apple a régi iCloud jelszót, hogy ismét syncelni tudjon a telefon. Másrészt jól hangzik ez a disk encryption, de valaki mondja már meg, hogy hol van a kulcs a titkosításhoz. Csak nem az is a készülékben? Azt meg jó esetben is csak a 4-6 számjegyű PIN kóddal védik, biztos nehéz lenne kipörgetni off-line, ha meg van a pontos algoritmus...

Gondolom
1. automatikusan már akkor sem szinkronizálna ha visszaállítanák az eredeti jelszót a szerveren.
2. a helyi hatóságok úgy változtatták meg az eredeti jelszót, hogy nem gondoltak arra, menteni kellene a szerveren az eredeti, számukra ismeretlen jelszó fájljait. Így már nincs rá mód az eredeti jelszó megszerzésére.
Ha az elkövetőknek volt annyi eszük, hogy ők változtattak jelszót a terrorcselekményük elkövetése előtt, akkor az archivált szervermentéseken sincs megfelelő jelszó.
A második esetet tartom valószínűbbnek.

Egyrészt nem is lenne rá szükség, hisz nem arról van szó, hogy a gyanúsított percenként változtatta a jelszavait hónapokon keresztül, másrészt biztos meglepődsz, de ilyen helyeken nem mysqldump>backup szintű mentések vannak, harmadrészt jelszavaknál is változáskövetés történik, ahogy Googlenél és a Microsoftnál is. Visszamenőleg meg van mindegyik korábbi jelszó, emiatt tudja a Google is bekérni a Gmailnél a korábbi jelszavaidat ellenőrzésre, ha elfelejtenéd a jelenlegit, de még a Windowsok is 15+ éve képesek ellenőrízni azt, hogy nem-e egy korábbi jelszavadat adtad meg újra jelszóváltoztatáskor.

Ha az elkövetőknek volt annyi eszük, hogy ők változtattak jelszót a terrorcselekményük elkövetése előtt, akkor az archivált szervermentéseken sincs megfelelő jelszó.
Apple!=Google Apple!=Microsoft
Továbbá lásd 1. lehetőség. De a második lehetőség továbbra sem zárható ki.

Ezek az elkövetők majdnem akkora IT expertek voltak, mint te, ezért is áll az Apple és az FBI széttárt kezekkel és körbe-körbe pingvineznek, hogy mitévők legyenek. Tuti ez lehet az igazság. Az teljesen kizárt, hogy az egész csak egy kibaszott színjáték...

Hiába, random kiddiek törnek fel és szivárogtatnak ki több gigányi hollywoodi celeb képet az icloudról, de ez a fránya Apple és FBI közösen sem képes egy terroristának az adataihoz hozzáférni.

Ez csak így lehet. Főleg mivel random lockozó hülyegyerek lánynévvel a hupon is ezt feltételezi.

Micsoda pech, hogy az Apple javitotta a fappening után a Find My iPhone hibáját. Most lehetne brútforszolni! Ja várj csak! Nem az iCloud adatok kellenének hanem az iPhone tartalma de két jelszó már nem passzol. Megint sikerült árnyékra vetődnöd. De folytasd csak! Még még még!! :)

Mivel a történet nagy részét hozzászólásokból raktam össze, ezért elképzelhető, hogy komolyabb lyukak vannak benne.
Én az tudom esetleg elképzelni, hogy elég ha a telefon egyszer belefut authentication errorba, ezután nem próbálkozik tovább, hanem manuálisan kell valamit csinálni.

A második felére egyetértek, a kulcs nyilván valami LUKS-hoz hasonló módon a telefonban van tárolva, csak azért nem tudják PIN kódot brute-force kipörgetni, mert 10 hibás próbálkozás után végleg törlődik. Ezért követlenek az Apple-től egy moddolt iOS-t, ami hagyja a brute force-ot.
---
Régóta vágyok én, az androidok mezonkincsére már!

Off-line törést írtam, ott nem játszik a lockout... Ki kell nyerni a titkosított adathalmazt és a titkosító kulcsot, amelyik le van védve a PIN kóddal. Mivel a 4-6 számjegyű PIN entrópiája nem túl sok, ezért végig lehet próbálni az összes variációt. Ehhez még csak szuperszámítógépre sincs szükség, törtem már fel ilyen jellegű védelmeket. Ezért nem hiszek a PIN kóddal védhető USB pendriveokban sem.

Azért nem biztos, hogy ez olyan egyszerű, hogy csak kiforrasztod a flash chipet, rákötöd a jtag-et és ledumpolod, aztán jöhet is a brute force.

Ha teljesen saját tervezésű custom zárt hardvered és teljesen saját fejlesztésű zárt szoftvered van, akkor egészen mások a lehetőségek, mint egy USB pendrive esetén. Már 20-25 éve vannak olyan hardveres megoldások (suicide battery és társai), amiknél a hozzápiszkálás hatására a kulcs elveszik, nem kizárt hogy itt is van valami hasonló. Elég kézenfekvő megoldás, hogy a kulcs nem ugyanazon a flash chipen van, amin az adatok, hanem mondjuk a CPU-n belül valami kis embedded eeprom-ban. Így buszról nem lehet lesniffelni. Szoftveresen pedig valószínűleg csak megfelelően autentikált kódból lehet hozzáférni (kb trusted boot szerűen).
---
Régóta vágyok én, az androidok mezonkincsére már!

Abban a világban ahol civilek törnek fel tamper-proof smart cardokat piacon elérhető eszközökkel csak azért, hogy ingyen tudják venni a műholdas TV adásokat, én nem nagyon hiszek abban, hogy a világ egyik legjobb nyomozó hatósága (amelyik máskor Tor és Firefox 0dayekkel töri meg a darknetes webshop üzemeltetőket) és a telefon saját gyártója ne tudná visszafejteni a tárolt adatokat. Az Applenél ott van minden info, tudja hogyan működik és hol tárolja a kulcsot, milyen kódolás mellett, nem kell találgatni. Ráadásul attól a comsumer gyártótól ne várjunk már katonai biztonságot felvonultató hardvereket, amelyik a 2 centtel nagyobb haszon reményében a macbookjaiból is elhagyta a TPM chipeket...

A trusted boot meg jól hangzik elméletben, de gyakorlatban néha triviálisabb hibáktól szenved, mint az ember gondolná. Arról már nem is beszélve, hogy amíg a RAM nincs titkosítva, addig fizikai hozzáférés esetén abban is szépen felül lehet csapni a PIN kód lockout kódját, vagy bármilyen más ellenőrzést, de akár saját kód beinjektálással a titkosító kulcsot is ki lehet nyerni.

Kurva messze vagyunk még a trusted computingtól, de persze álmodozni lehet, hogy már eljött... :)

Abban a világban ahol civilek törnek fel tamper-proof smart cardokat piacon elérhető eszközökkel
Ebben a világban vannak olyan arcade és konzoljátékok, amiket 20 évvel a megjelenésük után tudtak csak feltörni. link. Az az átkozott suicide battery megoldás meglepően jól tudja védeni a kulcsot.

Az általad felhozott példák ráadásul kicsit másmilyenek. Itt egy eszközön belül generált kulcs, ami oda soha nem megy be, onnan soha nem jön ki, olyan adathordozót véd, ami üzemszerűen a gépből soha nem kell kikerüljön, a gépen kívül soha nem kell kinyitni a titkosítását. Ezért mondom, hogy ez egy sokkal könnyebben megoldható feladat. Nem állítom, hogy az Apple hibátlanul oldotta meg, de az elvi lehetőség leginkább itt adott. A tartalomterjesztési DRM-ről tudjuk nagyon jól, hogy elvileg nem lehet tökéletesen megoldani.

a telefon saját gyártója ne tudná visszafejteni a tárolt adatokat. Az Applenél ott van minden info, tudja hogyan működik és hol tárolja a kulcsot, milyen kódolás mellett, nem kell találgatni.
A telefon gyártója vissza tudja, mert nekik megvan a saját aláíró kulcsuk, amivel olyan debug firmware-t töltenek rá, amilyet csak akarnak.

a 2 centtel nagyobb haszon reményében a macbookjaiból is elhagyta a TPM chipeket...
Az iPhone esetén teljesen custom CPU-t használnak, aminél elvileg belső IP-blockban is meg tudják oldani lényegében 0 költséggel.

a világ egyik legjobb nyomozó hatósága
FBI != NSA. Az FBI-nak a törvényi kereteken belül kell működniük. Nem csinálhatják meg, hogy akár valami zavaros nemzetbiztonsági "titkos törvényre" (bármennyire is abszurd) hivatkozva beállítanak az Apple-höz és egyszerűen elkérik a firmware aláíró kulcsot. Vagy ha nem kooperálnak (Snowden akták szerint erre is volt példa), akkor oldschool humán kémkedéssel megszerzik. Afelől nincs kétségem, hogy az NSA ki tudja nyitni azt a telefont. Afelől sem, hogy nemhivatalosan az FBI megtudakolta az NSA-től, hogy mit kellene tenniük ebben az esetben. De a kulcsot, vagy moddolt firmware-t nem hiszem, hogy átadták volna, mert ez jogilag már nagyon durva támadási felületet nyitna. Ha meg egy 0-day-el törhető, akkor az NSA hülye lesz átadni az FBI-nak, hogy utána a tárgyaláson fel kelljen fedni és ezzel bezáruljon ez a lehetőség.

Az FBI most legálisan próbálja kikényszeríteni ugyanazt a lehetőséget saját magának, ami az NSA-nak már illegálisan megvan.
---
Régóta vágyok én, az androidok mezonkincsére már!

Ebben a világban vannak olyan arcade és konzoljátékok, amiket 20 évvel a megjelenésük után tudtak csak feltörni.

De abban azért ugye egyetértünk, hogy az iPhone/iOS törésekre kicsit nagyobb a kereslet, mint 20 éves Z80 játékok másolásvédelmének törésére? ;)

Az iPhone esetén teljesen custom CPU-t használnak, aminél elvileg belső IP-blockban is meg tudják oldani lényegében 0 költséggel.

A fejlesztési költség sem nulla és a potenciális patent sértés sem, amelyet elkövetnek ezzel. A haszon közelebb áll a nullához számukra.

FBI != NSA. Az FBI-nak a törvényi kereteken belül kell működniük.

Amiket példának hoztam mind FBI akciók voltak és bőven a törvényi keretek között csinálták (pedig voltak meredek bitcoin lefoglalások és túlkapásos pedofil rajtaütések). Ehhez képest egy ilyen forensics feladat teljesen általános téma és mint írtam a RAM-os példát, nem kellenek hozzá nagyon extrém módszerek, ezek simán rendelkezésre állhatnak náluk, vagy valamelyik partnercégüknél.

Gondolhatod, hogy nem ez az első iPhone, amelyik az FBI kezébe került hogy hozzá akarnak férni a rajta lévő adatokhoz és most meglepődve tapasztalták, hogy PIN kódot kér a készülék...

Ahogy írtam korábban, ez is csak a pénzről szól. Az FBI-nak olcsóbb lenne a bírósági végzésre hivatkozva az Applere hárítani a feladatot és későbbiekben is így tenni (sőt lehetőleg univerzális megoldást találni a problémára), hogy ne drága szakértőket kelljen felkérni minden esetben. Az almás cég meg bolond lenne extra munkába vernie magát és elesni későbbi bevételektől.

1. Ok nyilván, viszont pont azért hoztam példának, mert a maiaknál lényegesen egyszerűbb megoldásról volt ott szó (bár ez a támadási lehetőségek számát inkább csökkenti)
2. A fejlesztési költség nem hiszem, hogy probléma lenne, mert iszonyatos darabszámra oszlik szét. Nem állítottam, hogy patentet sértenek, simán lehet in-house fejlesztés is, simán lehet licenszelt is, one time payment modellben.
3. Hát a fene tudja. Nekem a sok fenti részlet alapján legalábbis az a benyomásom, hogy itt tényleg beleütköztek valamibe, amit (legalábbis legálisan) nem tudnak megoldani. Pl volt rutin módszerük, de valamiért nem jött be, lehet hogy a jelszavas elbaltázás miatt, lehet, hogy más miatt. Ezt arra alapozom, hogy a korábbi ügyek jogi dokumentumaiban nyoma kellene lennie annak, amit mondasz, külső szakértőknek stb. - hiszen azért szereztek így bizonyítékokat, hogy utána bíróságon felhasználják, mindennek teljesen le kell papírozva lennie. Ha van nyoma, az Apple simán hivatkozhat arra, hogy korábban N db hasonló esetet meg tudtak oldani mókolt firmware nélkül, akkor most miért lett mégis elengedhetetlenül szűkséges?

De ebből igazából mind a Te, mind az Én következtetésemet egyformán le lehet vonni.
---
Régóta vágyok én, az androidok mezonkincsére már!

Ügyes gyerek! Amíg nem olvastam a soros ellenállást a vezetékeken, addig nem is hittem el az egészet. De attól kezdve hihetőnek tűnt.
Viszont ő is írja: "For a 6 digit passcode it would require over 160 thousand rewrites and will very likely damage the Flash memory storage."
Szóval a 6 számjegyú kulcs törése már valószínűleg nem menne ezzel a módszerrel. De biztosan tovább lehet fejleszteni, hogy az is meglegyen. Pl. ha már visszafejtette a NAND parancskészletét, akkor tehetne a NAND és a uC közé egy igen gyors FPGA-t, ami a kellő pillanatban (pl. sikertelen jelszó beírás után) írásvédetté teszi a NAND-et, így a 999999 próbálkozás nem járna 160k blokk törléssel.

Szerk.: de a legjobban az LGA levétel tetszett.

Szerk2.: abban igaza volt XMI-nek, hogy úgy néz ki, a Hynix az Apple kedvéért csinált valami nem dokumentált NAND parancskészletet. De azért túl nem bonyolították, mert egy egyetemi kutató ki bírta találni a parancsokat. Nyilván az FBI emberei is vissza bírták volna fejteni.

Másrészt jól hangzik ez a disk encryption, de valaki mondja már meg, hogy hol van a kulcs a titkosításhoz. Csak nem az is a készülékben? Azt meg jó esetben is csak a 4-6 számjegyű PIN kóddal védik, biztos nehéz lenne kipörgetni off-line, ha meg van a pontos algoritmus...

Innen a megjegyzés erre:

You mistake an iPhone's unlock code with the iPhone's encryption key. the iPhones do typically use a 4-6 digit pin as an unlock code. The user also has the ability to create a full alphanumeric password for the unlock code as well. However, that is simply the code that's used to unlock the actual full encryption key that is stored within dedicated crypto hardware. Apple uses a dedicated chip to store and process the encryption. They call this the Secure Enclave. The secure enclave stores a full 256-bit AES encryption key.

Within the secure enclave itself, you have the device's Unique ID (UID) . The only place this information is stored is within the secure enclave. It can't be queried or accessed from any other part of the device or OS. Within the phone's processor you also have the device's Group ID (GID). Both of these numbers combine to create 1/2 of the encryption key. These are numbers that are burned into the silicon, aren't accessible outside of the chips themselves, and aren't recorded anywhere once they are burned into the silicon. Apple doesn't keep records of these numbers. Since these two different pieces of hardware combine together to make 1/2 of the encryption key, you can't separate the secure enclave from it's paired processor.

The second half of the encryption key is generated using a random number generator chip. It creates entropy using the various sensors on the iPhone itself during boot (microphone, accelerometer, camera, etc.) This part of the key is stored within the Secure Enclave as well, where it resides and doesn't leave. This storage is tamper resistant and can't be accessed outside of the encryption system. Even if the UID and GID components of the encryption key are compromised on Apple's end, it still wouldn't be possible to decrypt an iPhone since that's only 1/2 of the key.

The secure enclave is part of an overall hardware based encryption system that completely encrypts all of the user storage. It will only decrypt content if provided with the unlock code. The unlock code itself is entangled with the device's UDID so that all attempts to decrypt the storage must be done on the device itself. You must have all 3 pieces present: The specific secure enclave, the specific processor of the iphone, and the flash memory that you are trying to decrypt. Basically, you can't pull the device apart to attack an individual piece of the encryption or get around parts of the encryption storage process. You can't run the decryption or brute forcing of the unlock code in an emulator. It requires that the actual hardware components are present and can only be done on the specific device itself.

The secure enclave also has hardware enforced time-delays and key-destruction. You can set the phone to wipe the encryption key (and all the data contained on the phone) after 10 failed attempts. If you have the data-wipe turned on, then the secure enclave will nuke the key that it stores after 10 failed attempts, effectively erasing all the data on the device. Whether the device-wipe feature is turned on or not, the secure enclave still has a hardware-enforced delay between attempts at entering the code: Attempts 1-4 have no delay, Attempt 5 has a delay of 1 minute. Attempt 6 has a delay of 5 minutes. Attempts 7 and 8 have a delay of 15 minutes. And attempts 9 or more have a delay of 1 hour. This delay is enforced by the secure enclave and can not be bypassed, even if you completely replace the operating system of the phone itself. If you have a 6-digit pin code, it will take, on average, nearly 6 years to brute-force the code. 4-digit pin will take almost a year. if you have an alpha-numeric password the amount of time required could extend beyond the heat-death of the universe. Key destruction is turned on by default.

Even if you pull the flash storage out of the device, image it, and attempt to get around key destruction that way it won't be successful. The key isn't stored in the flash itself, it's only stored within the secure enclave itself which you can't remove the storage from or image it.

Each boot, the secure enclave creates it's own temporary encryption key, based on it's own UID and random number generator with proper entropy, that it uses to store the full device encryption key in ram. Since the encryption key is also stored in ram encrypted, it can't simply be read out of the system memory by reading the RAM bus.

The only way I can possibly see to potentially unlock the phone without the unlock code is to use an electron microscope to read the encryption key from the secure enclave's own storage. This would take considerable time and expense (likely millions of dollars and several months) to accomplish. This also assumes that the secure enclave chip itself isn't built to be resistant to this kind of attack. The chip could be physically designed such that the very act of exposing the silicon to read it with an electron microscope could itself be destructive.

TLDR: Brute forcing the unlock code isn't at all possible through pretty much any means...reasonable or even unreasonable...maybe...JUST MAYBE...it's possible through absurdly unreasonable means.

--
The Elder Scrolls V: Skyrim

Apple doesn't keep records of these numbers.

RSA Inc. ugyanezt ígérte a SecureID terméke kapcsán ha emlékszünk, aztán amikor betörtek hozzájuk, akkor hamarosan kiderült, hogy ezeket a seed számokat is lenyúlták tőlük és ezek segítségével hajtottak végre sikeres támadást Lockheed Martin ellen...

Másrészt ahogy a smart cardoknál utaltam, azért nem ördögtől való megoldás az sem, hogy a chipekből kinyerik az egyedi azonosítókat és titkosító kulcsokat. Látni ilyeneket és ezeknél cifrább megoldásokat is. Pl. Chris Tarnovsky elég jó ebben és pár "feltörhetetlen" chipről már bebizonyította korábban, hogy mégse az. Kormányzati körökben pedig erre méginkább vannak csapatok, FBI-nak is külön computer forensics labja van ilyen esetekre.

Egyébként ilyen secure enclave van az újabb Intel Skylake procikban is, de csak az Intel által aláírt kódokat lehet benne futtatni, amelyik megint arra lesz jó, hogy a titkosszolgálatok majd képesek lesznek olyan rootkiteket létrehozni és telepíteni, amelyeket le se lehet vadászni, mert a processzor fogja védeni és titkosítva tárolni...

( Hunger | 2016. 02. 20., szo – 11:23 )

Ez (is) csak a pénzről szól. Nyilván akár egy Apple-független biztonsági cég is unlockolni tudja a telefont (sőt, valószínűleg az FBI állományában is van olyan szakértő, aki képes erre), csak az FBI azt akarja elérni, hogy legyen számukra egy univerzális kiskapu, amelyik mindig működik, gyorsan tudjanak az adatokhoz hozzáférni akár a nyomozók is és ne kelljen külön egyesével szakértőt felkérni.

( papp_jozsef v | 2016. 02. 20., szo – 11:57 )

Az FBI-nak nem fognak engedni, és kitartanak, de biztos vagyok benne, hogy mindig is volt és lesz is backdoor, csak nem adják ki az FBI-nak. Miért pont az Appleben biznék meg? Ez is csak egy vállalat. Csak addig marad igy a jelenlegi helyzet, amig nem áll majd más a részvényesek érdekében.

( sigellef | 2016. 02. 20., szo – 12:38 )

az erősebb kutya ba... ...llag el a csonttal

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
/usr/lib/libasound.so --gágágágá --lilaliba

( dejo v | 2016. 02. 20., szo – 12:46 )

A magyar kormány is megfenyegette a Telekomot, hogy felbontja a kormány szerződéseket velük, mert Ákost meg ákombákomozták!
Na most, ha az USA kormánya kezd el fenyegetőzni, azt komolyan kell venni! :)
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

( Hiena v | 2016. 02. 20., szo – 21:52 )

Az egész csak egy pitiáner show műsor. Az Apple és az összes többi nagy cég akkora privacy adatbázisokkal rendelkezik, hogy az összes állami szerv megnyalná az összes ujját utána. Eddig a hárombetűsök nem nagyon ugráltak, és nem nagyon akartak mit kezdeni ezzel a mézes bödönnel, de mostanában egyre inkább nyalintanának belőle. A techcégek nem adják, mert fosnak, hogy a [del]birkák[/del] tisztelt felhasználók szarrá perelnék őket, ha a biztonságban hitt csöcsös-pöcsös képeik a hatóság kezébe kerülnének.
Ez a kutyahecc, nem a telefonról szól.
A techcégeknek azt a látszatot kell tartaniuk, hogy ők védik a felhasználók adatait. (Annak ellenére, hogy a rendszrgazdáik a kiskorú, tiniribanc felhasználóik, felhőbe fellőtt, meztelen képeire verik.)
A hatóságnak kell egy precedens, hogy a techcégek ajtajának résébe ékelhessék a lábukat. Ma egy telefon, holnap az összes privát üzenet, holnapután öt másodpercenként egy geotaggelt kép a telefonról.
A céges backdoorok már mind ott figyelnek a telefonokon, amióta a szolgáltató/gyártó alkalmazásokat telepíthet és törölhet a felhasználó telefonjáról. Ezt a menetet már rég elvesztette az átlagember, mikor hagyta, hogy ne legyen teljes kontrollja a készüléke felett.

--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Ne légy naiv.Ez csak egy parasztvakítás, hogy a paraszt azt higgye van kontrollja.
Az megvan, hogy nem is kell rendelkezned google accounttal, csak kellőképp ritkán törölnöd a cookiekat a böngésződben? Hogy a mozgásodat az Androidos készülékek a látható hotspotok ESSID-jei és cellainformációk alapján folyamatosan küldik kifelé? Hogy semmiféle garancia nincs rá, hogy egy készüléken használt login információk nem kerülnek rögzítésre a gyártónál?
Az okostelefonnál a legnagyobb "man in the middle" pont a mobil OS gyártó, lévén a felhasználókról begyűjtött adatok és a felhasználói szokások értékesítésével kompenzálja az OS fejlesztésből kiesett pénzösszeget.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

( tigrincs | 2016. 02. 21., v – 22:25 )

Kiderult hogy van e backup az icloudban?
Ha van akkor ott van a kulcs naluk (hiszen ha a felhasznalo telefonja megsemmisul akkor nem erne semmit a backup es nem lehetne egy uj telefonra lehuzni az adatokat)

( zrubi v | 2016. 02. 22., h – 10:12 )

Tényleg van aki azt gondolja/elhiszi hogy létezik backdoor mentes zárt forráskódú szoftver?

Disclaimer: I am not speaking on behalf of my employer, this is my personal opinion

--
zrubi.hu