Інженери з компанії Intel запропонували новий протокол HTTPA (HTTPS Attestable), який розширює HTTPS додатковими гарантіями безпеки вироблених обчислень. HTTPA дозволяє гарантувати цілісність обробки запиту користувача на сервері і переконатися в тому, що web-сервіс заслуговує на довіру і код, що працює в TEE-оточенні (Trusted Execution Environment), не був змінений в результаті злому або диверсії адміністратора.
HTTPS захищає дані на етапі передачі по мережі, але не може виключити порушення їх цілісності в результаті атак на сервер. Ізольовані анклави, які створюються за допомогою таких технологій, як Intel SGX (Software Guard Extension), ARM TrustZone та AMD PSP (Platform Security Processor), дають можливість захистити важливі обчислення та знизити ризик витоків або зміни конфіденційної інформації на кінцевому вузлі.
HTTPA для гарантування достовірності переданої інформації дозволяє задіяти засоби атестації, що надаються в Intel SGX, що підтверджують справжність анклава, в якому зроблено обчислення. Насправді HTTPA розширює HTTPS можливістю віддаленої атестації анклаву і дозволяє перевірити те, що він виконується в справжньому оточенні Intel SGX і можна довіряти web-сервісу. Протокол спочатку розвивається як універсальний і, крім Intel SGX, може бути реалізований і для інших TEE-систем.
Крім штатного для HTTPS процесу встановлення захищеного з'єднання, HTTPA додатково вимагає узгодження сесійного ключа, що заслуговує на довіру. Протокол вводить у вжиток новий HTTP-метод «ATTEST», який дозволяє обробляти три типи запитів та відповідей:
- "preflight" для перевірки, чи підтримує віддалена сторона атестацію анклавів;
- attest для узгодження параметрів атестації (вибір криптографічного алгоритму, обмін унікальними для сеансу випадковими послідовностями, генерація ідентифікатора сеансу та передача клієнту відкритого ключа анклаву);
- "trusted session" - формування сесійного ключа для довірчого обміну інформацією. Сесійний ключ формується на основі раніше узгодженої попередньої секретної послідовності (pre-session secret), сформованої клієнтом з використанням отриманого від сервера відкритого ключа TEE, та згенерованих кожною стороною випадкових послідовностей.
HTTPA передбачає, що клієнт заслуговує на довіру, а сервер немає, тобто. клієнт може використовувати цей протокол для верифікації обчислень у TEE-оточенні. При цьому HTTPA не гарантує, що інші обчислення, що виробляються в процесі роботи web-сервера, не в TEE, не були скомпрометовані, що вимагає застосування окремого підходу до розробки web-сервісів. Таким чином, в основному HTTPA націлений на використання зі спеціалізованими сервісами, до яких висуваються підвищені вимоги до цілісності інформації, такі як фінансові та медичні системи.
Для ситуацій коли обчислення TEE повинні бути підтверджені як для сервера, так і для клієнта передбачений варіант протоколу mHTTPA (Mutual HTTPA), що виконує двосторонню верифікацію. Цей варіант більш ускладнений через необхідність двостороннього формування сесійних ключів для сервера та клієнта.
Джерело: opennet.ru