Почти всеки ден в мрежата се появяват новини за поредната хакерска атака или за изтичане на информация от iCloud на потребителите. Повечето от тях просто не защитават достатъчно своя профил и следователно са склонни към лесно хакване.
Тогава как можете надеждно да се защитите? Нека ви кажем как.
Задайте динамична парола
Това не е някаква специална комбинация, която се променя сама. Това е паролата, която измисляте. Просто трябва да се сменя на редовни интервали. И за предпочитане без добавяне на една цифра или буква наведнъж.
Добрата парола трябва да е дълга поне 8 знака, включително главни и малки букви, цифри и различни символи. Пример е hJil5 &% GAf.
Включете двуфакторното удостоверяване
Този метод се счита за най-надежден поради факта, че изисква потвърждение за влизане от друго устройство чрез SMS или push съобщение.
Етап 1... Отидете на Настройки -> iCloud. Докосваме Apple ID.
Стъпка 2... Щракнете върху Парола и сигурност.
Стъпка 3... Докоснете Активиране на двуфакторна автентификация.
Използване на мениджър на пароли
Използването на сложни пароли е трудна задача, защото трябва да ги държите всички в главата си. Safari има вградено управление на пароли, което е достатъчно добро, ако използвате браузъра на всичките си устройства.
Самостоятелните програми обаче предлагат допълнителна функционалност. Можем да препоръчаме 1Password. Главната парола, необходима за влизане в приложението, не се съхранява в ключодържателя на iOS. Защитата от груба сила е гарантирана от SHA512 и PBKDF2 и всеки запис във вашата база данни е криптиран с 256-битов ключ (AES).
Което ви позволява да запазвате информация за акаунта и номера на кредитни карти.
Във връзка с
В резултат на това всички данни могат да бъдат синхронизирани с надеждни устройства. Mac, iPhone, Ай Пади iPod Touchкоито са свързани с едно.
Това развитие на събитията още веднъж доказва зависимостта Appleот iCloud, и повишава отговорността на администраторите на облачната услуга на компанията, които са длъжни да гарантират безопасността на личните данни на потребителите.
Appleпубликува специален материал за прилагането на сигурността и поверителността на потребителите в услугата iCloud... С изход OS X Mavericksправилата са леко актуализирани.
Помислете за работа в iCloudв детайли. Ако потребителят влезе в акаунта си в сайта iCloud.comпрез браузър, тогава всичките му сесии са защитени със SSL сертификат, включително трафик, циркулиращ между устройства и услуги iCloud... Всякакви данни в уеб приложенията iCloud, които са достъпни чрез уеб интерфейса или други основни приложения iOS / OS Xса криптирани на сървъра. Единствените изключения са IMAP пощенските сървъри. За да криптирате данни, съхранявани на IMAP сървъри, трябва да използвате допълнително S / MIME криптиране, което се поддържа от всички пощенски клиенти Apple.
V Appleсъщо така заявява, че достъпът до основни приложения като поща, контакти и календар се осъществява чрез защитени токени, които не осигуряват съхранение на пароли от iCloudна джаджи и компютри.
„Дори ако решите да използвате приложения на трети страни, за да получите достъп iCloud, вашето потребителско име и парола се изпращат чрез криптирана SSL връзка “, известието от Apple.
Относно функциите и Намерете моите приятелив компанията Apple уверяват, че координатите на местоположението се записват само по искане на потребителя. Тези функции използват най-малко 128-битово AES криптиране. Най-новите заснети данни за местоположението се съхраняват на сървъри Apple: за Намерете моите приятелисрокът на съхранение е 2 часа и 24 часа. След това цялата информация се изтрива.
За съхранение на пароли и номера на кредитни карти на сървъри iCloud Appleизползва 256-битово AES криптиране и "криптография с асиметрична елиптична крива и симетрични ключове", за да гарантира сигурността на личните данни. Тези стандартни методи за криптиране се използват както за предаване, така и за съхранение на данни в облака.
Що се отнася до номерата на кредитни карти, записани с Ключови гроздовеслед това в iCloudсъхраняват се само номерата на карти и датите на валидност, а не кодовете за сигурност (cvv), които се въвеждат ръчно в уеб формуляри. В допълнение, данните от Ключови гроздовене са част от резервното копие в iCloud.
Ако искате да избегнете архивирането на вашите данни в Ключодържателтогава трябва да пропуснете стъпката за генериране на кода за защита при конфигуриране Ключови гроздове... Това ще гарантира, че вашите данни са от Ключови гроздовесе съхраняват локално и се синхронизират само с устройствата, които потребителят използва. Трябва да се помни, че в този случай (без използване на код за сигурност) Appleняма да може да възстанови вашите данни от Ключови гроздове.
Компанията подчертава, че нямат достъп до ключовете за криптиране за Ключови гроздоветъй като те се създават локално на устройствата на потребителите.
Да използвам Купчина ключовеНа iPhone, iPod touchи Ай Пад, всички устройства трябва да работят на базата и на компютрите Macтрябва да се инсталира OS X Mavericks... Използването на функцията зависи от региона, в който живее потребителят.
ICloud Music Library улеснява преместването на снимки и видеоклипове между устройства. Това означава, че нашата медия се съхранява някъде на сървърите и също така постоянно се движи онлайн между нас и сървърите. Но дали тези данни са безопасни?
Как Apple защитава снимките?
Всички данни, които се прехвърлят към медийната библиотека на iCloud, са защитени в движение с най-малко AES криптиране с дължина на ключа от най-малко 128 бита. Защитата се осъществява както по време на предаване, така и при съхранение на данни.
Ключовете за криптиране не се прехвърлят на трети страни при никакви обстоятелства.
Тази фраза, взета от официалния сайт за поддръжка на Apple, подчертава, че можете да сте спокойни за вашите данни.
При прехвърляне на данни към сървъри или при изтегляне на данни от iCloud, той се използва криптиране от край до край... Това означава, че дори някой да прихване тези данни (но какво ако!), той няма да може да види снимката или видеото.
Apple използва AES и SHA за силно криптиране и хеширане на данни. Много финансови институции използват тези стандарти.
В своя документ за сигурност Apple пише:
Всеки файл се разделя на парчета и се криптира от iCloud с помощта на AES-128 и ключ, извлечен от съдържанието на всяка част с помощта на SHA-256. Ключовете и файловите метаданни се съхраняват от Apple в техния iCloud акаунт. Криптираните парчета от файла се съхраняват без никаква информация за идентифициране на потребителя, като се използват услуги за съхранение като Amazon S3 и Windows Azure.
Такива предпазни мерки са достатъчно добри за съхраняване на снимки на милиони потребители по целия свят.
Apple е чувствителен към проблемите с поверителността. Следователно в системните настройки е посветен цял раздел. Там можете да разрешите/забраните достъпа до вашите снимки за различни приложения.
Също така, всяка програма, която има нужда от достъп до снимката, при първата употреба, не забравяйте да попитате потребителя за нея. Това е направено, така че Apple да няма въпроси как тази или онази снимка се е озовала, например, в Instagram.
Откъде идват периодично частни снимки на известни личности от iCloud? Защо от време на време се появяват статиите „Още изтичане в iCloud“? За съжаление, никакво криптиране не може да ви спаси от човешката глупост. В 100 процента от случаите така наречените хакери просто налагат паролата за iCloud с груба сила. Но Apple направи всичко възможно, за да гарантира, че това никога не се случва.
в) Не забравяйте да зададете силна парола на вашите iOS устройства и компютри. Пример: Компютърът ви попада в грешни ръце. Има проста парола. А паролата от компютъра отваря не само достъп до него, но и достъп до ключодържателя.
Съхраняването на пароли сигурно и синхронизирането им между устройства не е лесна задача. Преди около година Apple представи на света iCloud Keychain, своя централизиран магазин за пароли за OS X и iOS. Нека се опитаме да разберем къде и как се съхраняват потребителските пароли, какви потенциални рискове носи и дали Apple технически може да получи достъп до декриптирани данни, съхранявани на сървърите му. Компанията твърди, че такъв достъп е невъзможен, но за да се потвърди или отрече това, е необходимо да се разбере как работи iCloud Keychain.
iCloud 101
Всъщност iCloud не е само една услуга, това е общо маркетингово име за гамата от облачни услуги на Apple. Това включва синхронизиране на настройки, документи и снимки и Find My Phone за намиране на изгубени или откраднати устройства и iCloud Backup за архивиране в облака, а сега ето iCloud Keychain за сигурно синхронизиране на пароли и номера на кредитни карти между устройства, базирани на iOS и OS X...
Всяка услуга iCloud се намира в собствен домейн от трето ниво, като pXX-keyvalueservice.icloud.com, където XX е номерът на сървърната група, отговорна за обработката на заявки от текущия потребител; този номер може да е различен за различните Apple ID; по-новите акаунти обикновено имат по-висока стойност за този брояч.
Код за сигурност на ICloud
Преди да се потопим в анализа на iCloud Keychain, нека да разгледаме как е конфигурирана тази услуга. Когато iCloud Keychain е включен, потребителят е подканен да измисли и въведе код за защита на iCloud (iCloud Security Code, по-долу - iCSC). По подразбиране формата за въвеждане ви позволява да използвате четирицифрен цифров код, но като кликнете върху връзката „Разширени опции“, все още можете да използвате по-сложен код или дори да оставите устройството да генерира силен произволен код.
Вече знаем, че данните в iCloud Keychain са защитени от iCSC. Е, нека се опитаме да разберем как точно се изпълнява тази защита!
Прихващане на трафик или човек в средата
Първата стъпка в анализа на мрежовите услуги често е получаването на достъп до мрежовия трафик между клиента и сървъра. В случая с iCloud има две новини за нас: добра и лоша. Лошото е, че целият (е, или поне по-голямата част от него) трафик е защитен от TLS / SSL, тоест е криптиран и не може да бъде „прочетен“ от обикновена пасивна атака. Добрата новина е, че Apple даде на всеки, който иска да изследва iCloud, подарък и не използва закрепване на сертификати, което улеснява организирането на атака човек в средата и дешифрирането на прихванатия трафик. За това е достатъчно:
- Поставете експерименталното iOS устройство в една и съща Wi-Fi мрежа с прихващащия компютър.
- Инсталирайте прихващащ прокси сървър (като Burp, Charles Proxy или друг подобен) на компютъра.
- Импортирайте TLS / SSL сертификата на инсталирания прокси сървър на iOS устройството (подробности в помощта на конкретния прокси сървър).
- В настройките на Wi-Fi мрежата на iOS устройството (Настройки → Wi-Fi → Име на мрежа → HTTP прокси) посочете IP адреса на прихващащия компютър в Wi-Fi мрежата и порта, на който прокси сървърът слуша.
Ако всичко е направено правилно, тогава целият трафик между устройството и iCloud ще бъде с един поглед. И от прихващането на този трафик ще се види ясно, че iCloud Keychain е изграден на базата на две iCloud услуги: com.apple.Dataclass.KeyValue и com.apple.Dataclass.KeychainSync - както при първоначално, така и при многократно включване на други устройства с iOS обменя данни с тези услуги.
Първата услуга не е нова и беше сред първите функции на iCloud; той се използва широко от приложенията за синхронизиране на настройките. Вторият е нов и е разработен, очевидно, специално за iCloud Keychain (въпреки че функционалността му теоретично ви позволява да го използвате за други цели). Нека разгледаме по-отблизо тези услуги.
com.apple.Dataclass.KeyValue
Както бе отбелязано по-горе, това е една от услугите, използвани от iCloud Keychain. Много съществуващи приложения го използват за синхронизиране на малки количества данни (настройки, отметки и други подобни). Всеки запис, съхранен от тази услуга, е свързан с идентификатор на пакета и име на магазин. Съответно, за да получите съхранените данни от услугата, е необходимо също така да предоставите тези идентификатори. В iCloud Keychain тази услуга се използва за синхронизиране на записите на Keychain в криптирана форма. Този процес е описан достатъчно подробно в документа за сигурност на iOS под Синхронизиране на ключодържател и Как работи синхронизирането на ключодържател.
Синхронизиране на ключодържател
Когато потребителят за първи път включи iCloud Keychain, устройството създава кръг на доверие и синхронизираща идентичност (публични и частни ключове) за текущото устройство. Публичният ключ на тази двойка се поставя в „кръг на доверие“ и този „кръг“ се подписва два пъти: първо с частния ключ за синхронизиране на устройството, а след това с асиметричен ключ (базиран на елиптична криптография), извлечен от паролата на потребителя в iCloud . Също така, "кръгът" съхранява параметри за изчисляване на ключа от паролата, като сол и броя на повторенията.
Подписаният "кръг" се записва в хранилището за ключ/стойност. Тя не може да бъде прочетена без да се знае паролата на потребителя за iCloud и не може да бъде променена без да се знае частния ключ на едно от устройствата, добавени в кръга.
Когато потребител включи iCloud Keychain на друго устройство, това устройство има достъп до хранилището на ключ/стойност в iCloud и забелязва, че потребителят вече има „кръг на доверие“ и че новото устройство не е включено в него. Устройството генерира ключове за синхронизиране и разписка за заявка за членство в кръг. Разписката съдържа публичния ключ за синхронизиране на устройството и е подписана с ключ, получен от паролата за iCloud на потребителя, като се използват параметрите за генериране на ключ, получени от хранилището за ключ/стойност. След това подписаната разписка се поставя в хранилището за ключ/стойност.
Първото устройство вижда новата разписка и показва на потребителя съобщение, че новото устройство иска да бъде добавено в кръга на доверие. Потребителят въвежда паролата за iCloud и подписът на разписката се проверява за коректност. Това доказва, че потребителят, генерирал заявката за добавяне на устройство, е въвел правилната парола при създаването на разписката.
След като потребителят потвърди добавянето на устройството в кръга, първото устройство добавя публичния ключ за синхронизиране на новото устройство към кръга и го подписва отново два пъти, като използва своя частен ключ за синхронизиране и използвайки ключа, получен от паролата за iCloud на потребителя. Новият „кръг“ се записва в iCloud и новото устройство го подписва по същия начин.
Как работи синхронизирането на Keychain
Сега има две устройства в "кръга на доверие" и всяко от тях знае публичните ключове за синхронизиране на други устройства. Те започват да обменят записи на Keychain чрез iCloud Key / Value storage. Ако един и същ запис присъства и на двете устройства, приоритет ще бъде даден на модификацията, която има по-късен момент. Ако времето за промяна на запис в iCloud и на устройството е едно и също, тогава записът не се синхронизира. Всеки запис за синхронизиране е криптиран специално за целевото устройство; не може да бъде декриптиран от други устройства или Apple. Освен това записът не се съхранява постоянно в iCloud - той се презаписва от новите синхронизирани записи.
Този процес се повтаря за всяко ново устройство, добавено в кръга на доверие. Например, ако към кръга се добави трето устройство, тогава заявката за потвърждение ще се покаже на другите две устройства. Потребителят може да потвърди добавянето на всеки от тях. Когато се добавят нови устройства, всяко устройство в кръга се синхронизира с новите, за да се гарантира, че наборът от записи е еднакъв за всички устройства.
Трябва да се отбележи, че не целият Keychain е синхронизиран. Някои записи са свързани с устройството (като VPN акаунти) и не трябва да напускат устройството. Синхронизират се само записи, които имат атрибута kSecAttrSynchronizable. Apple е задала този атрибут за потребителски данни на Safari (включително потребителски имена, пароли и номера на кредитни карти) и за пароли за Wi-Fi.
Също така по подразбиране записите от приложения на трети страни също не се синхронизират. За да ги синхронизират, разработчиците трябва изрично да зададат атрибута kSecAttrSynchronizable, когато добавят запис към Keychain.
iCloud Keychain работи с две хранилища:
- com.apple.security.cloudkeychainproxy3
- com.apple.sbd3
Предполага се, че първият магазин се използва за поддържане на списък с надеждни устройства (устройства в „кръг на доверие“, между които е разрешено синхронизиране на пароли), за добавяне на нови устройства към този списък и за синхронизиране на записи между устройства (в съответствие с механизма описано по-горе).
Второто хранилище е предназначено за архивиране и възстановяване на Keychain записи на нови устройства (например, когато няма други устройства в "кръга на доверие") и съдържа криптирани Keychain записи и свързана информация.
По този начин записите на Keychain се съхраняват в редовно хранилище за ключ/стойност (com.apple.securebackup.record). Тези записи са криптирани с помощта на набор от ключове, съхранявани там (BackupKeybag). Но този набор от ключове е защитен с парола. Откъде идва тази парола? Какво представлява услугата парола на Apple Escrow? След това ще се опитаме да го разберем.
apple.Dataclass.KeychainSync
Това е нова услуга, тя възникна сравнително наскоро: за първи път нейната поддръжка се появи в бета версии на iOS 7, след това тя отсъстваше в iOS 7.0–7.0.2 и беше добавена повторно в iOS 7.0.3, която беше пусната на пазара. едновременно с пускането на OS X Mavericks. Това е услугата за ескроуване на парола, спомената по-горе (адресът на услугата е pXX-escrowproxy.icloud.com).
Услугата е предназначена да съхранява сигурно потребителски тайни и позволява на потребителя да възстанови тези тайни след успешно удостоверяване. За успешно удостоверяване се нуждаете от следното:
- Токен за удостоверяване на iCloud, получен в замяна на Apple ID и парола по време на първоначалното удостоверяване към iCloud (стандартният метод за удостоверяване за повечето iCloud услуги);
- iCloud код за сигурност (iCSC);
- шестцифрен цифров код, изпратен от сървърите на Apple до номера на мобилен телефон, свързан с потребителя.
Това изглежда добре на теория, но за да определим дали теорията е същата като практиката, трябва да направим одит на клиентската програма за escrow. В iOS и OS X тази програма се нарича com.apple.lakitu. Описанието на процеса на неговото обръщане и одит е извън обхвата на статията, така че нека да преминем направо към резултатите.
Налични команди
Одитът com.apple.lakitu ви позволява да дефинирате списък с команди, изпълнявани от услугата escrow. Съответната екранна снимка показва командите и техните описания. Особено бих искал да се спра на последната команда - с нейна помощ е възможно да промените телефонния номер, свързан с текущия акаунт. Наличието на тази команда прави многофакторното удостоверяване, използвано за възстановяване на iCloud Keychain (парола на Apple ID + iCSC + устройство), значително по-малко надеждно, тъй като елиминира един от факторите. Интересното е, че потребителският интерфейс на iOS не ви позволява да изпълните тази команда - той просто няма такава опция (поне аз не я намерих).
Особеността на тази команда, която я отличава от всички останали, е, че изисква удостоверяване с паролата на Apple ID и няма да работи, ако токенът iCloud се използва за удостоверяване (другите команди работят с удостоверяване на токен). Това служи като допълнителна защита за екипа и показва, че системните дизайнери са предприели стъпки за подобряване на неговата сигурност. Не е съвсем ясно обаче защо тази команда изобщо присъства в системата.
Възстановяване на депозирани данни
За получаване на депозираните данни се изпълнява следният протокол:
- Клиентът изисква списък с депонирани записи (/get_records).
- Клиентът изисква свързан телефонен номер, на който сървърът ще изпрати код за потвърждение (/get_sms_targets).
- Клиентът инициира генерирането и доставянето на код за потвърждение (/generation_sms_challenge).
- След като потребителят е въвел iCSC и SMS кода за потвърждение, клиентът инициира опит за удостоверяване с помощта на протокола SRP-6a (/ srp_init).
- След като получи отговор от сървъра, клиентът извършва изчисленията, предписани от протокола SRP-6a, и изисква депонираните данни (/възстановяване).
- Ако клиентът е успешно удостоверен, сървърът връща депозираните данни, като предварително ги е криптирал върху ключа, генериран по време на операцията на протокола SRP-6a (ако протоколът работи успешно, тогава и сървърът, и клиентът изчисляват този споделен ключ).
Важно е да се отбележи, че телефонният номер, получен в стъпка 2, се използва изключително за нуждите на потребителския интерфейс, тоест, за да покаже на потребителя номера, на който ще бъде изпратен кодът за потвърждение, а в стъпка 3 клиентът не изпрати на сървъра номера, на който трябва да бъде изпратен кодът за потвърждение.
Сигурна отдалечена парола
В стъпка 4 клиентът стартира протокола SRP-6a. Сигурна отдалечена парола (SRP) е протокол за удостоверяване на парола, който е защитен от подслушване и атаки от човек в средата. Така например, когато се използва този протокол, е невъзможно да се прихване хешът на паролата и след това да се опита да го възстанови, просто защото не се предава хеш.
Apple използва най-модерната версия на протокола, SRP-6a. Тази опция инструктира за прекратяване на връзката, ако удостоверяването не успее. Освен това Apple разрешава само десет неуспешни опита за удостоверяване за дадена услуга, след което всички последващи опити се блокират.
Подробно описание на протокола SRP и неговите математически основи е извън обхвата на тази статия, но за пълнота, по-долу е частна версия, използвана от услугата com.apple.Dataclass.KeychainSync.
SHA-256 се използва като хеш функция H, а 2048-битовата група от RFC 5054 „Използване на протокола за защитена отдалечена парола (SRP) за TLS удостоверяване“ се използва като група (N, g). Протоколът работи както следва:
- Устройството генерира произволна стойност a, изчислява A = g ^ a mod N, където N и g са параметрите на 2048-битовата група от RFC 5054 и изпраща съобщение до сървъра, съдържащо потребителския идентификатор, изчислената стойност на A и SMS кода за потвърждение. Стойността DsID, уникален цифров идентификатор на потребител, се използва като потребителски идентификатор.
- След като получи съобщението, сървърът генерира произволна стойност b и изчислява B = k * v + g ^ b mod N, където k е факторът, дефиниран в SRP-6a като k = H (N, g), v = g ^ H (Salt, iCSC) mod N е средство за проверка на паролата, съхранявано на сървъра (аналог на хеш на парола), Salt е произволна сол, генерирана при създаване на акаунт. Сървърът изпраща съобщение до клиента, съдържащо B и Salt.
- Чрез прости математически трансформации клиентът и сървърът изчисляват общия ключ на сесията K. Това завършва първата част от протокола - генериране на ключа - и сега клиентът и сървърът трябва да се уверят, че получават една и съща K стойност.
- Клиентът изчислява M = H (H (N) XOR H (g) | H (ID) | Salt | A | B | K), доказателство, че знае K, и изпраща M и SMS кода за потвърждение към сървъра. Сървърът също изчислява M и сравнява получената от клиента и изчислената стойност; ако не съвпадат, сървърът прекратява изпълнението на протокола и прекратява връзката.
- Сървърът доказва знанията за K на клиента, като изчислява и изпраща H (A, M, K). Сега и двете страни по протокола не само са разработили общ ключ, но и са се уверили, че този ключ е един и същ и за двете страни. В случай на услугата escrow, сървърът също така връща произволен вектор за инициализация IV и escrow запис, криптиран на споделения ключ K, използвайки алгоритъма AES в режим CBC.
Използването на SRP за допълнителна защита на потребителските данни, според мен, значително подобрява сигурността на системата от външни атаки, дори и само защото ви позволява ефективно да се противопоставяте на опитите за груба сила iCSC: можете да опитате само една парола за връзка с услугата . След няколко неуспешни опита акаунтът (в рамките на работата с услугата escrow) се прехвърля в състояние на меко заключване и временно се блокира и след десет неуспешни опита акаунтът се заключва напълно и по-нататъшната работа с услугата escrow е възможна само след като iCSC за акаунта бъде нулиран.
В същото време използването на SRP не защитава по никакъв начин от вътрешни заплахи. Депозираната парола се съхранява на сървърите на Apple, така че може да се предположи, че Apple има достъп до нея, ако е необходимо. В този случай, ако паролата не е била защитена (например криптирана) преди escrow, това може да доведе до пълен компрометиране на записите в Keychain, съхранявани в iCloud, тъй като escrowed паролата ще позволи декриптиране на ключове за криптиране, а те - Keychain записи (обърнете внимание на com. apple.Dataclass.KeyValue).
Въпреки това, в документа за сигурност на iOS, Apple заявява, че специализирани хардуерни модули за сигурност (HSM) се използват за съхраняване на дескриптирани записи и че не може да се получи достъп до escrow данни.
Ескроу сигурност
iCloud предоставя сигурна инфраструктура за escrow на Keychain, като гарантира, че Keychain се възстановява само от оторизирани потребители и устройства. HSM клъстерите защитават депонирани записи. Всеки клъстер има свой собствен ключ за криптиране, който се използва за защита на записите.
За да възстанови ключодържателя, потребителят трябва да се удостовери с потребителското име и паролата на iCloud и да отговори на изпратения SMS. Когато това е направено, потребителят трябва да въведе код за защита на iCloud (iCSC). HSM клъстерът проверява коректността на iCSC, използвайки протокола SRP; iCSC не се предава към сървърите на Apple. Всеки възел в клъстера, независимо от останалите, проверява дали потребителят е превишил максималния брой опити за извличане на данни. Ако проверката е успешна на повечето възли, клъстерът декриптира дешифрирания запис и го връща на потребителя.
След това устройството използва iCSC, за да декриптира дешифрирания запис и да получи паролата, използвана за криптиране на записите в Keychain. Използвайки тази парола, Keychain, получен от хранилището на ключ/стойност, се декриптира и възстановява на устройството. Разрешени са само десет опита за удостоверяване и извличане на депозираните данни. След няколко неуспешни опита записът се блокира и потребителят трябва да се свърже с поддръжката, за да го деблокира. След десетия неуспешен опит, HSM клъстерът унищожава депонирания запис. Това осигурява защита срещу атаки с груба сила, насочени към получаване на запис.
За съжаление, не е възможно да се провери дали HSM действително се използват. Ако всичко е вярно и HSM не позволява четене на съхраняваните в тях данни, тогава може да се твърди, че данните на iCloud Keychain са защитени от вътрешни заплахи. Но, отново, за съжаление, е невъзможно да се докаже или опровергае използването на HSM и невъзможността за четене на данни от тях.
Остава още един начин за защита на данните от вътрешна заплаха - защита на депонираните данни на устройството преди прехвърлянето им към сървърите на Apple. От описанието на Apple следва (и обръщането потвърждава това), че такава защита е приложена - депозираната парола е предварително криптирана с помощта на iCSC. Очевидно в този случай нивото на сигурност (от вътрешната заплаха) зависи пряко от сложността на iCSC и четирисимволният iCSC по подразбиране не осигурява достатъчна защита.
И така, разбрахме как работят отделните елементи на системата и сега е моментът да разгледаме цялата система.
Събирайки всичко заедно
Диаграмата показва работата на iCloud Keychain по отношение на депозиране и възстановяване на Keychain записи. Системата работи по следния начин:
- Устройството генерира набор от произволни ключове (в терминологията на Apple - keybag) за криптиране на Keychain записи.
- Устройството криптира записите в Keychain (с набора атрибути kSecAttrSynchronizable), като използва набора от ключове, генериран в предишната стъпка, и съхранява криптираните записи в хранилището за ключ/стойност com.apple.sbd3 (ключ com.apple.securebackup.record).
- Устройството генерира произволна парола, състояща се от шест групи по четири знака всяка (ентропията на такава парола е около 124 бита), криптира набора от ключове, генерирани в стъпка 1, използвайки тази парола, и съхранява криптирания набор от ключове в ключа / Съхранение на стойност com.apple.sbd3 (BackupKeybag).
- Устройството криптира произволната парола, генерирана в предишната стъпка, като използва ключа, получен от кода за сигурност на iCloud на потребителя, и депозира криптираната парола в услугата com.apple.Dataclass.KeychainSync.
Когато настройва iCloud Keychain, потребителят може да използва сложен или произволен iCSC вместо четирицифрения код по подразбиране. Ако се използва сложен код, механизмът на депозитната система не се променя; единствената разлика е, че ключът за криптиране на произволната парола ще бъде изчислен не от четирицифрения iCSC, а от по-сложния, въведен от потребителя.
При произволен код подсистемата за escrow парола изобщо не се използва. В този случай произволната парола, генерирана от системата, е iCSC и задачата на потребителя е да я запомни и съхранява безопасно. Записите в Keychain все още са криптирани и се съхраняват в хранилището за ключ/стойност com.apple.sbd3, но услугата com.apple.Dataclass.KeychainSync не се използва.
заключения
Спокойно можем да кажем, че от техническа гледна точка (тоест не разглеждаме социалното инженерство) и по отношение на външни заплахи (тоест не на Apple), сигурността на услугата escrow iCloud Keychain е на достатъчно ниво: благодарение на използването на протокола SRP, дори ако паролата на iCloud е компрометирана, нападателят няма да има достъп до записите на Keychain, тъй като това допълнително изисква код за защита на iCloud и повторението през този код е значително трудно.
В същото време, използвайки друг механизъм на iCloud Keychain - синхронизиране на пароли, нападател, който е компрометира паролата на iCloud и има кратък физически достъп до едно от устройствата на потребителя, може напълно да компрометира iCloud Keychain: за това е достатъчно да добавите паролата на нападателя устройство към „кръга на доверие“ на устройствата на потребителя и за това е достатъчно да знаете паролата на iCloud и да имате краткосрочен достъп до устройството на потребителя, за да потвърдите заявката за добавяне на ново устройство към „кръга“.
Ако разгледаме защитата срещу вътрешни заплахи (тоест Apple или някой с достъп до сървърите на Apple), тогава в този случай сигурността на услугата escrow не изглежда толкова розова. Твърденията на Apple за използването на HSM и невъзможността за четене на данни от тях нямат убедителни доказателства, а криптографската защита на депонираните данни е обвързана с кода за сигурност на iCloud, като настройките по подразбиране са изключително слаби и позволяват на всеки, който може да извлечете от сървърите на Apple (или HSM), депозираните записи, възстановете вашия четирицифрен код за сигурност на iCloud почти незабавно.
В случай на сложен буквено-цифров код, тази атака става по-трудна, тъй като броят на възможните пароли се увеличава. Ако iCloud Keychain е конфигуриран да използва произволен код, тогава услугата escrow изобщо не участва, което на практика прави този вектор на атака невъзможен.
Максималното ниво на сигурност (без да се брои пълното изключване на iCloud Keychain, разбира се) се осигурява при използване на произволен код - и не толкова, защото такъв код е по-труден за намиране, а защото подсистемата за депониране на пароли не участва , и следователно повърхността на атака е намалена. Но удобството на тази опция, разбира се, оставя много да се желае.
ICloud Keychain е незаменим помощник в съхраняването на важна и тайна информация. Всички пароли се записват от приложението Safari в облачното хранилище. Няма нужда да записвате или запаметявате сложни пароли сами, куп ключове ще ви помогнат да запомните и отворите всичко.
Ако използвате приложението iCloud Keychain, въведете кода за сигурност на iCloud. Кодът може да бъде шестцифрен, цифров или буквено-цифров или генериран автоматично. Този код ви позволява да възстановите данни, ако устройството е загубено, както и да извършите определени действия при идентифициране на потребител. Това е допълнителна защита, но кодът трябва да е такъв, че да не го забравяте и запомняте. Ако въведете кода неправилно и дори няколко пъти, ключодържателят ще бъде блокиран на това устройство. За да възобновите работата, свържете се с Apple Technical Services за удостоверяване и отключване.
Когато активирате ключовете, можете да пропуснете въвеждането на кода за сигурност и да пропуснете тази стъпка, след което информацията няма да се съхранява в облака.
Настройка на пакет
Ако е невъзможно да потвърдите влизането от друго устройство в приложението на новото устройство, използвайте защитния код, след като въведете който, потвърдете връзката чрез SMS. На всяко устройство на Apple, за да конфигурирате приложението, отидете в менюто "Настройки", изберете "iCloud", потърсете приложение с ключове. Когато щракнете върху иконата на приложението, ще се появи превключвател, плъзнете го, за да го активирате. Въведете вашата парола за ID и продължете с инструкциите. Сега имате достъп до най-важната функция - автоматизирането на въвеждане на всякакви пароли и кодове. Плащайте за покупки лесно, отидете на сайтове, имейл без колебание.
Сигурност на кредитни карти
Трезорът съдържа номера на кредитни карти и дати на изтичане. Номерата за безопасност не остават в паметта. Прекъсването на връзката с приложението не изтрива данните.
Някои проблеми при използване на приложението и начини за решаването им
Кодът не е получен чрез SMS
- Уверете се, че този телефонен номер е свързан към вашия акаунт.
- Проверете тарифния си план, за да разберете дали SMS известията са забранени.
Проверете номера, който е свързан с акаунта, отидете на "Настройки", изберете "iCloud keychain", отидете на раздела "Разширени". В секцията „Номер за проверка“ се въвежда телефонен номер.
Социалните пароли не се показват на устройствата
В секцията „Предпочитания“ отворете „Safari“ и отидете на „AutoComplete“. Проверете дали акаунтът за имена и пароли работи. Ако изключите тази функция, паролите не се запомнят. След това натиснете Начало и проверете Safari. Ако прозорецът на програмата е черен, деактивирайте режима "Частен достъп".
Понякога популярните уебсайтове не дават разрешение за запазване на паролите на своите посетители, така че техните пароли няма да бъдат запазени.
Ако загубите достъп до някое от устройствата
Ако загубите достъп до едно от устройствата, трябва да създадете друг код за защита. Отидете на "Настройки", изберете приложението, отидете в раздела "Разширени". Изберете „Потвърдете с код за сигурност“ и изберете раздела „Забравен код“. Активирайте Reset Keychain. Потвърдете действията си и създайте нова парола.
Съобщение за промяна на кода
Ако се появи съобщението за промяна на кода за сигурност, не го пренебрегвайте. Не е необходимо да актуализирате кода за сигурност, но системата трябва да бъде актуализирана. Ако не изпълните тези стъпки, съобщението ще се появи отново. Ако игнорирате това съобщение и не отговорите, като отметнете „не сега“, ключодържателят ще бъде изключен след третия отказ. Синхронизацията няма да се случи на други устройства и ще бъде невъзможно да се възстанови приложението през сайта.
Когато се появи това съобщение, е възможно да се актуализира. Кликнете върху „създаване“ и следвайте предложените действия.
Грешен код е въведен много пъти
Ако въведете грешен код няколко пъти, връзката ще бъде деактивирана. Облачният ключодържател просто ще бъде изтрит. Потвърдете това устройство с друго или нулирайте приложението.
Изключете услугата на всички устройства
Ако изключите тази услуга от всички устройства, вашият пакет ще бъде премахнат от облака. За да възобновите работата, конфигурирайте услугата отново.
Всеки път, когато актуализирате софтуера на всяко устройство на Apple, трябва да преконфигурирате и пакета. За да направите това, отидете в настройките на iCloud и включете клавишите, като преместите плъзгача. След това следвайте инструкциите и настройте устройството си отново.
Сигурност
Apple спазва политиката за поверителност и информацията, получена от потребителите на техните продукти, не се разкрива. Информацията се предава в криптирана форма, ключовете не могат да бъдат прехвърлени на някой друг. Информацията за местоположението на притурката ще се съхранява за не повече от един ден в облака и след това ще бъде изтрита за постоянно.
Ако имате проблеми със сдвояването, проверете настройките в устройството.
