Na zahtjev FBI-ja Apple odustao od kriptiranja iCl

End-to-end enkripcija znači da samo krajnji uređaji korisnika u stanju dekriptirati podatke. Kod komunikacijskih protokola dva uređaja mogu ključ razmijeniti direktno pomoću asimetrične enkripcije. Kod backupa vezanog uz uređaj, ključ nikad ne napušta uređaj. Međutim, da bi se backup mogao dekriptirati na uređaju koji nikad nije direktno komunicirao s originalnim uređajem, a da pri tom enkripcija i dalje bude end-to-end, ključ ne smije biti poznat servisu, već ga korisnik mora sam ubaciti u novi uređaj (ukucati, spojiti USB stick na kojem je ključ pohranjen i sl). Ako novi uređaj može povući i podatke i ključ sa servisa, onda to nije end-to-end konekcija.

U pravu si da devotion nije izričito napisao da su podaci vezani za uređaj, međutim, inzistiranjem na tvrdnji da se radi o end-to-end enkripciji, uz poznatu činjenicu da ne postoji ključ poznat korisniku, a nepoznat servisu, implicitno tvrdi i da su podaci vezani za uređaj (jer po načelu end-to-end nekripcije nitko drugi ne može imati ključ).

Kriptiranje podataka na uređaju na način da servis može dekriptirati podatke ili ključ nije end-to-end enkripcija, već client side enkripcija, što sam već napisao u prethodnom postu.

P.S. Umjesto da nagađamo, predložio bih da pričekamo da devotion prezentira dokaze kojima raspolaže.

I što si sad napisao? Da ipak po defaultu ide client-side, a ne end-to-end enkripcija, međutim, ako ugasiš backup na iCloud samo sa end-to-end enkripcijom? To baš ulijeva povjerenje.

Ovo a certifikatima - radio sam to i uredno je prolazilo s ugašenim drugim uređajima, korištenjem telefonske verifikacije. To je čisti 2fa i ne dokazuje ništa.

 -hmmm...? -ne.

ili, vidi ovako, prvo naslov-tema, pa onda da to kao uvode od 2017me ali još nisu i neće.. dakle, dovoljan je ovaj članak-tema da bi imao 'dokaz' kako te enkricpije u cloudu nema.

-čitav igrokaz uopće nije problem FBI i sl, tj prisutup podacima (jer ga imaju) nego pravni, zaštitia, kao pismo-ustav-zakon i te sitnice, tj to što fbi može pročitati sudski ne pomaže u postupku, odnosno, bez sudskog naloga je to propupravno pribavljen dokaz time bezvrijedan + kažnjiv za fbi.. jer ni fbi ne smije provaljivati, tj mora imati opravdani razlog, tj nalog suda (osim izuzetka kao npr pedofilija-terorizam i sl.) a pristup milionima uređaja i podacima koirsnika dok nemaju opravdani razlog ili nalog, ne mogu tumačiti kao terorizam.. odnosno, jesu li svi stanovnici zemlje ili usa teroristi? .. to je problem, pravni i pokriće, ne može li fbi do podataka jer može a kao što vidimo to ni nije problem npr enkripcije jer je ni nema.

- Apple šifrira podatke na iCloudu, ne razumijem što je tu sporno osim tvom nevjerovanju činjenicama koje ne potvrđuje Apple već i neovisni istražitelji.

- U drugom paragrafu pokušavam tvojoj kaši u glavi objasniti po treći put APPLE IMA END-TO-END ENKRIPCIJU za "Apple Keychain" i "Health data". 

- O jebem te živote. U trećem paragrafu (u kojem se nikad ničemu nisam nadao) već pišem kako je Apple najavio prije nešto manje od 2 godine potpunu end-to-end enkripciju cijelog iClouda. Evo ponovo citat, iako ne vjerujem da ćeš ga shvatiti pa da pročitaš ovo 10 puta: "Apple je najavio end-to-end enkripciju cijelog iClouda i mnogi su koji prate Apple tu istu end-to-end enkripciju očekivali na ovogodišnjem WWDC-u, a hoće li na kraju to i uvesti vidjet ćemo" 

Čitaj, a ne palamudi o nečemu tako jednostavnom kao tuđi komentar koji očito ne možeš shvatiti. Taman dok to pročitaš, jer znam da ti to ništa ne vrijedi probat ću "dogovoriti" live chat s voditeljem sigurnosti u Appleu :-)

"Each file is broken into chunks and encrypted by iCloud using AES-128 and a key derived from each chunk’s contents, with the keys using SHA-256. The keys and the file’s metadata are stored by Apple in the user’s iCloud account. The encrypted chunks of the file are stored, without any user-identifying information or the keys, using both Apple and third-party storage services—such as Amazon Web Services or Google Cloud Platform—but these partners don’t have the keys to decrypt the user’s data stored on their servers.

iCloud also backs up information—including device settings, app data, photos, and videos in the Camera Roll, and conversations in the Messages app—daily over Wi-Fi. iCloud secures the content by encrypting it when it’s when sent over the Internet, storing it in an encrypted format, and using secure tokens for authentication. iCloud Backup occurs only when the device is locked, connected to a power source, and has Wi-Fi access to the Internet. Because of the encryption used in iOS and iPadOS, iCloud Backup is designed to keep data secure while allowing incremental, unattended backup and restoration to occur.

When files are created in Data Protection classes that aren’t accessible when the device is locked, their per-file keys are encrypted, using the class keys from the iCloud Backup keybag, and backed up to iCloud in their original, encrypted state. All files are encrypted during transport and, when stored, encrypted using account-based keys, as described in CloudKit.

The iCloud Backup keybag contains asymmetric (Curve25519) keys for Data Protection classes that aren’t accessible when the device is locked. The backup set is stored in the user’s iCloud account and consists of a copy of the user’s files and the iCloud Backup keybag. The iCloud Backup keybag is protected by a random key, which is also stored with the backup set. (The user’s iCloud password isn’t used for encryption, so changing the iCloud password won’t invalidate existing backups.)

While the user’s Keychain database is backed up to iCloud, it remains protected by a UID-tangled key. This allows the Keychain to be restored only to the same device from which it originated, and it means no one else, including Apple, can read the user’s Keychain items.

On restore, the backed-up files, iCloud Backup keybag, and the key for the keybag are retrieved from the user’s iCloud account. The iCloud Backup keybag is decrypted using its key, then the per-file keys in the keybag are used to decrypt the files in the backup set, which are written as new files to the file system, thus reencrypting them according to their Data Protection class.

Many Apple services use end-to-end encryption with a CloudKit Service Key protected by iCloud Keychain syncing. For these CloudKit containers, the key hierarchy is rooted in iCloud Keychain and therefore shares the security characteristics of iCloud Keychain—namely, the keys are available only on the user’s trusted devices, and not to Apple or any third party. If access to iCloud Keychain data is lost the data in CloudKit is reset; and if data is available from the trusted local device, it’s uploaded again to CloudKit. "

 Ja šumom ti drumom. Po tebi bitno je zakomplicirat život korisniku end-to-end enkripcije, jer link koji si poslo ne govori ništa o čemu ja pišem (pozadina kako sve to radi) već je to link s jebenim uputama za korištenje iCloud keychaina. End-to-end enkripcija funkcionalna je ako se na kraju može otključat SAMO od strane onoga koji ju je inicirao, a po tebi je end-to-end enkripcija način na koji se to može otključati. Drugim riječima nije najbitnije imati najsigurniju bravu na vratima, već ključ od 2 kile u džepu dok hodaš u sefu?

Evo još jednom pozadina kako to stvarno iza "jednostavnog unošenja sigurnosnog koda" zaista radi i to se zove end-to-end enkripcija.

The diagram shows the escrow process and recovery of Keychain records in iCloud Keychain. The system works as follows:

1. 1. The device generates a set of random keys (‘keybag’ in Apple terminology) to encrypt the Keychain records.
2. 2. The device encrypts the Keychain records (which have the enabled attribute ‘kSecAttrSynchronizable’) with a set of keys generated in the previous step and stores the encrypted records in Key/Value store ‘com. apple. sbd3’ (key ‘com. apple. securebackup. record’).
3. 3. The device generates a random password, which consists of six groups of four characters (the entropy of such a password is about 124 bit), encrypts the set of keys generated in step 1 by using this password and saves the encrypted set of keys in Key/Value store ‘com. apple.sbd3’ (key ‘BackupKeybag’).
4. 4. The device encrypts a random password generated in the previous step by using the key obtained from the iCloud security code of the user and escrows the encrypted password to the service ‘com.apple.Dataclass.KeychainSync’.

When configuring his/her iCloud Keychain, the user can apply a complex or random iCSC instead of a 4-digit code prompted by default. When you use a complex code, the mechanism of escrow system does not change; the only difference is that the key for encrypting a random password will be computed not from the four-digit iCSC but from a more complex code entered by the user.
In case of a random code, the password escrow engine is not used at all. Moreover, the random password generated by the system is iCSC, which the user must remember and store safely. The Keychain records are encrypted and stored in Key/Value store ‘com.apple.sbd3’ in the same way, but the service ‘com.apple.Dataclass.KeychainSync’ is not used.