Уявіть, що ваше завдання — створити веб-сервіс, який зберігає всі дані в конфіденційності, навіть від команди, яка керує інфраструктурою. Наприклад, система дозволяє страховим агентам порівнювати своїх клієнтів у реальному часі, щоб виявити шахрайство. Ця інформація настільки цінна, що ніхто не може довіряти керувати цією службою, якщо людина може отримати доступ до неї.
https://snellingswalters.com/understanding-eap-confidentiality/
Один із підходів — використання традиційних перевірок і балансів, таких як фізичний захист серверної кімнати, але це дорого і не дуже ефективно.
Наша мета — спроектувати систему, яка зберігає конфіденційність даних і в той же час є дешево керованою. Рішення в цій статті буде використовувати існуючу інфраструктуру HTTPS, конфіденціальне обчислення та економічні стимули для досягнення цієї мети. Інший спосіб поглянути на це — рішення вимагатиме довіри тільки до людей і систем, які не мають прямого доступу до даних і мають достатньо мотивації для того, щоб бути надійними.
Ми побудуємо рішення крок за кроком, додаючи елементи по черзі, визначаючи, що не вистачає, і потім повторюючи процес.
З'єднання захищене
Коли користувач підключається до вебсайту, такого як "https://www.foo.com", вони мають гарантію того, що вони спілкуються з сервером, що належить тому, хто володіє доменом "foo.com". Користувачі зазвичай набувають впевненості через соціальні засоби, що "foo.com" належить відомій "Foo Corporation". HTTPS гарантує, що ніхто інший не може побачити дані, які вони обмінюються. Не провайдер інтернет-послуг (ISP), не власник Wi-Fi, не уряд і жоден хакер.
Щоб підтримувати HTTPS, адміністратор foo.com володіє парою ключів і сертифікатом, підписаним довіреною організацією. Усі браузери та операційні системи містять вбудований список прийнятих організацій для завершення кола довіри. Тому, якщо хакер перехоплює трафік і намагається представити себе як "Foo", він не зможе показати дійсний сертифікат для цього імені, і браузер попередить користувача.
Зображення нижче демонструє налаштування HTTPS сертифіката та те, як він забезпечує безпеку трафіку.
https://www.hostinger.com/tutorials/what-is-ssl
Дані захищені
Ми побачили, як HTTPS гарантує, що атакуючий не зможе підробити доменне ім’я, з яким ви підключаєтесь. Тепер давайте спробуємо поліпшити це, розглянувши, як ми могли б переконати користувачів, що жодна людина не зможе отримати доступ до даних, які вони подають на сервер.
Наприклад, у нашій гіпотетичній системі виявлення шахрайства конкуренти не хочуть, щоб реальні дані в реальному часі були видимі для адміністраторів системи, оскільки вони можуть бути схильні продати їх.
Коли браузер говорить, що "З'єднання захищене", це не означає, що "foo.com" не продасть ваші дані рекламодавцям.
У ідеальному світі, після введення URL-адреси в адресному рядку браузера, з’являється зелена галочка "Дані захищені" для сервісів, які пропонують цю додаткову гарантію.
Давайте почнемо розробляти уявне рішення, використовуючи конфіденційне обчислення. Це рішення використовує функції, які поки що не доступні, але це корисно для розуміння проблеми та перших складових практичного рішення.
Сертифікат "Дані захищені"
Програма, що працює в безпечній зоні, може повідомити вимір, але це не дуже корисно.
Наприклад, браузер, який відображає: "Ви підключені до сервера, що працює з програмою з хешем 0x74d1c…" не викликає у користувача впевненості в тому, що їхні дані захищені.
Нам потрібен спосіб перейти від цього твердження до людськочитної "Дані захищені".
Аналогічно тому, як веб "Сертифікаційні органи" (CA) прив'язують ім'я до криптографічного ключа, перевіряючи та засвідчуючи ідентичність, ми повинні ввести "Аудиторів конфіденційних обчислень (CCSA)". Це авторитетні компанії, які можуть перевірити вихідний код і підписати сертифікат, підтверджуючи, що програма зберігатиме дані конфіденційними, якщо вона буде запущена на безпечному обладнанні.
CCSA прив'язує гарантію конфіденційності даних до вимірювання програми.
Сертифікат "Дані захищені"
У цій ідеальній моделі, на додаток до надійних CAs, браузери повинні підтримувати список довірених CCSAs.
HTTPS у зашифрованому середовищі
Як ми побачили вище, HTTPS вже шифрує дані між двома кінцевими точками і гарантує, що ніхто в середині не може їх прочитати.
Для того, щоб побудувати наше конфіденційне рішення, ми повинні гарантувати, що браузер встановлює HTTPS-з'єднання безпосередньо з зашифрованим середовищем.
Щоб переконатися, що на іншому кінці є зашифроване середовище, браузер повинен виконати простий протокол, який перевіряє Атестацію контрагента. Потім, на основі звіту атестації та сертифіката CCSA, він може з упевненістю відобразити галочку "Дані захищені".
Зверніть увагу, що перевірка атестації має виконуватися безпосередньо браузером. Вона не може покладатися на завантажений JavaScript, оскільки JavaScript файл буде надано сервісом, що перевіряється.
З цим рішенням всі дані шифруються під час передачі (HTTPS), обробки (конфіденційні обчислення), а також у спокої, якщо вони зберігаються в зашифрованій базі даних.
У цьому ідеальному рішенні кінцевий користувач повністю довірятиме браузеру для прийняття найкращих рішень від її імені. Браузер знає, яким CAs і CCSAs довіряти, і тому може повідомити користувача, що з'єднання та дані є захищеними.
Веб-сертифікат, створений у зашифрованому середовищі
На жаль, описане вище рішення залежить від функцій, які ще не реалізовані в браузерах, але ми повинні побудувати цей сервіс сьогодні.
Ідея для першого елемента практичного рішення в тому, що пара ключів, що підтримує веб-сертифікат, може бути згенерована в зашифрованому середовищі.
Це означає, що будь-яке TLS-з'єднання, що використовує цей конкретний сертифікат, гарантовано завершиться в зашифрованому середовищі, оскільки ніхто інший не матиме відповідного приватного ключа.
CCSA повинна перевірити та засвідчити, що ця функціональність реалізована безпечно, тому логічний результат сертифіката CCSA буде: "Ми гарантуємо, що, на нашу найкращу відомість, якщо HTTPS-з'єднання встановлено за допомогою включеного веб-сертифіката, дані будуть захищені".
Оскільки браузер не має вбудованої підтримки для захищених даних, він не зможе відобразити "Дані захищені". Однак це не буде великою проблемою для користувачів, якщо вони отримають URL-адресу "www.securedataservice.com" від надійного джерела, наприклад, їхнього роботодавця.
Зверніть увагу, що користувачі, які хочуть скористатися сервісом, мають виконати додатковий крок — відвідати надійний вебсайт і перевірити, чи є цей додаток затвердженим. Лише після цього можна безпечно відвідати сайт.
Цей крок дозволяє прив'язати доменне ім'я до зашифрованого середовища. UX залишається життєздатним, навіть якщо перевірка не є автоматичною, якщо вона має виконуватися лише один раз перед першим використанням сервісу.
"Подвійне витрачання" веб-сертифікатів
Браузер, підключаючись до URL, перевіряє, що сертифікат, який надається сервером під час TLS-рукостискання, підписаний одним із CAs, яким він налаштований довіряти.
Наприклад, вебсайт не зобов'язаний мати єдиний сертифікат, тому "foo.com" теоретично може використовувати кілька сертифікатів, деякі з яких мали б ключі, згенеровані поза зашифрованим середовищем.
Якщо наш гіпотетичний постачальник конфіденційних послуг хоче переглянути дані користувача, він може отримати другий веб-сертифікат і представити його деяким користувачам. Якщо ці користувачі не перевіряють ключ з сертифіката CA з тим, що знаходиться в сертифікаті CCSA, їхні дані можуть бути передані на звичайний сервер, що не працює в зашифрованому середовищі, і користувачі ніколи не дізнаються. Це неприпустимо, оскільки порушує припущення довіри, які ми заявили для практичного рішення.
Наше завдання на цьому етапі — прибрати цей останній елемент, де користувачі повинні довіряти постачальнику послуг.
Децентралізовані протоколи знайшли розумні способи доповнити технічні рішення криптоекономічними стимулами, показуючи, що величезну цінність можна забезпечити таким чином.
Ця проблема схожа на ту, яку вирішує протокол Ethereum proof-of-stake, який запобігає подвійним підписам валідаторів. В обох випадках девіантна поведінка може бути доведена криптографічно.
У випадку Ethereum провайдер подає кілька підписів одного й того ж валідатора на суперечливі блоки. У нашому випадку перевіряючий може довести шкідливу поведінку постачальника послуг, подавши другий сертифікат CA для того самого домену.
Примітка: на схемі вище, якщо Боб був підключений за допомогою спеціальної програми, він міг би зберегти сертифікат, наданий під час TLS рукостискання, і отримати винагороду.
Щоб утримати сервіс чесним, перевіряючі випадковим чином встановлюватимуть з'єднання з URL з різних IP-адрес, використовуючи програму, що перевіряє сертифікат. Умова така, що сервер не повинен відрізняти між запитом "перевірки дійсності" та звичайним, щоб не дати операторам можливість робити Volkswagen.
Девіантні валідатори Ethereum караються "слашингом", що означає, що протокол конфіскує їхній внесок. Ідея полягає в тому, що погану поведінку можна або запобігти в реальному часі, зробивши її неможливою, або сильно покарати, якщо вона буде виявлена пізніше. Обидва підходи є практичними.
Примітка: Ідеальне рішення "Конфіденційного веб-сервісу", описане спочатку, запобігло б шахрайству постачальника послуг, оскільки браузер міг би відразу виявити це під час перевірки Атестації.
Ключовим елементом для рішення покарання є "Внесок у гру".
Корпоративні послуги, такі як наш гіпотетичний сервіс перевірки шахрайства, можуть бути перевірені учасниками. Якщо постачальник відхиляється, він втрачає свою репутацію і таким чином бізнес.
Публічні сервіси можуть ставити криптовалюту разом з CCSA в децентралізованому смарт-контракті. Контракт виплатить ставку будь-кому з альтернативним сертифікатом для того самого домену.
З цим останнім елементом у нас є повне рішення для нашого Конфіденційного веб-сервісу. Більше того, рішення є здійсненним навіть без явної галочки "Дані захищені", оскільки криптовалюта вже довела, що кінцеві користувачі охоче використовують перевірені програми, якщо вони чують про програму від надійного джерела.
Сервіс перевірки шахрайства в реальному часі
Тепер ми готові завершити наш гіпотетичний сервіс перевірки шахрайства.
Компанія з розробки програмного забезпечення пише програму, яка виконує логіку, що допомагає деяким жорстким конкурентам співпрацювати. Потім вони розгортають програму на зашифрованому середовищі та інструктують середовище створити сертифікат CA для їхнього нового домену "www.live-fraud.com".
Потім вони звертаються до "Let's Encrypt", де вони доводять свою особистість і отримують підписаний Web CA сертифікат, який знову подають у зашифроване середовище.
Потім вони наймають авторитетну компанію з аудиту безпеки, яка підпише звіт, що підтверджує дві речі:
- Web CA сертифікат дійсно був згенерований у зашифрованому середовищі.
2.
Наприклад, браузер, що відображає: "Ви підключені до сервера, що виконує програму з хешем 0x74d1c…", не викликає у користувача впевненості, що їхні дані захищені.
Нам потрібен спосіб перейти від цього до людського читаємого "Дані захищені".
Подібно до того, як Web "Certificate Authorities" (CA) прив'язують ім'я до криптографічного ключа, перевіряючи та засвідчуючи ідентичність, ми повинні впровадити "Аудиторів безпеки конфіденційних обчислень" (CCSA). Це авторитетні компанії, які можуть перевіряти вихідний код і підписувати сертифікат, що підтверджує, що програма зберігає дані конфіденційними, якщо її запускати на безпечному апаратному забезпеченні.
CCSA прив'язує гарантію конфіденційності даних до вимірювання програми.
Сертифікат "Дані захищені"
У цій ідеальній моделі, окрім надійних CA, браузери повинні підтримувати список довірених CCSA.
HTTPS у зашифрованому середовищі
Як ми бачили вище, HTTPS вже шифрує дані між двома кінцевими точками та гарантує, що ніхто в середині не може їх прочитати.
Щоб побудувати наше конфіденційне рішення, ми повинні забезпечити, щоб браузер встановлював HTTPS з'єднання безпосередньо з зашифрованим середовищем.
Щоб переконатися, що на іншому кінці є зашифроване середовище, браузер повинен виконати простий протокол, який перевіряє Атестацію контрагента. Потім, на основі атестаційного звіту та сертифікату CCSA, він може впевнено відображати галочку "Дані захищені".
Зверніть увагу, що перевірка Атестації повинна бути виконана безпосередньо браузером. Вона не може покладатися на завантажений JavaScript, оскільки JavaScript файл буде наданий сервісом, що проходить перевірку.
З цим рішенням всі дані шифруються під час передачі (HTTPS), під час обробки (конфіденційні обчислення), і тоді, коли зберігаються в зашифрованій базі даних.
У цьому ідеальному рішенні кінцевий користувач повністю довірятиме браузеру, щоб він приймав найкращі рішення від її імені. Браузер знає, яким CA і CCSA довіряти, і тому може повідомити користувача, що з'єднання та дані захищені.
Веб-сертифікат, згенерований всередині зашифрованого середовища
На жаль, описане вище рішення залежить від функцій, які ще не реалізовані в браузерах, але ми повинні побудувати цей сервіс вже сьогодні.
Ідея для першого елементу практичного рішення полягає в тому, що ключова пара, що підтримує Веб-сертифікат, може бути згенерована всередині зашифрованого середовища.
Це означає, що будь-яке TLS-з'єднання, яке використовує цей конкретний сертифікат, гарантується завершитися в зашифрованому середовищі, оскільки ніхто інший не буде мати відповідного приватного ключа.
CCSA повинні перевірити і підтвердити, що ця функціональність реалізована безпечно, тому логічний результат сертифікату CCSA буде: "Ми гарантуємо, що на основі наших знань, якщо HTTPS-з'єднання встановлено за допомогою включеного веб-сертифікату, дані захищені".
Оскільки браузер не має вбудованої підтримки захищених даних, він не зможе відобразити "Дані захищені". Однак це не є великою проблемою для користувачів, якщо вони отримають URL "www.securedataservice.com" від надійного джерела, наприклад, їхнього роботодавця.
Зверніть увагу, що користувачі, які хочуть скористатися сервісом, повинні виконати додатковий крок і відвідати довірений вебсайт, щоб перевірити, чи схвалено застосунок, який вони хочуть використовувати. Тільки тоді можна безпечно відвідати сайт.
З цим кроком ми прив'язали доменне ім'я до зашифрованого середовища. UX є здійсненним навіть якщо перевірка не автоматична, поки вона має бути виконана лише один раз перед першим використанням сервісу.
"Подвійне витрачання" Веб-сертифікатів
Браузер, що підключається до URL, перевірить, чи підписаний сертифікат, наданий сервером під час TLS рукостискання, одним з CA, яким він налаштований довіряти.
Перекладено з: Building a confidential Web Service