Представим себе такую модель безопасности. Она не полностью надежна, но обладает механизмом наращивания надежности. У нас есть три действующих лица.
1) Клиент - пользователь браузера
2) Сервис - предоставляет хранилище, например профиль соцсети.
3) Хранилище ключей - сторонний сервис, который по OAuth дает доступ з различным хранилищам ключей
Задача - разрешить пользователю пользоваться сервисом, у которого полностью открытый исходный код клиента - необфусцированый JS, который гарантировано не отправляет определенные данные на сервер. Если он отправит, то автоматически теряет доверие и пользователя. С другой стороны он содержит данные на сервере и никто не может проверить как именно он их читает. Нужно обеспечить чтобы он не мог читать личные данные пользователя, которые хранит. Сервис определим как «тайно-злонамереный», он хочет читать данные пользователя, но никогда не покажет это на клиенте, исходный код которого все могут читать и будет на клиенте вести себя честно.
Решение. Пользователь хранит данные на сервисе в зашифрованом виде в формате encrypted key->encrypted value. encrypted key - или зашифрованый ключ или 0 (начальный обьект из которого видно остальные). В таком виде оно приходит на клиент. Клиент делает запрос в хранилище ключей по данному ключу и получает ключ разшифровки, который разшифровывает на клиенте encrypted value. Таким образом можно расшифровать что угодно и добраться до любых encrypted value пользователя, если начать исследовать его данные с фиксированого ключа «0», последовательно расшифровывая обьекты.
Но что если само хранилище ключей для определенного пользователя пойдет в сервис и само начнет читать данные? Дело в том, что хранилище ключей не знает смысла ключей, ведь они зашифрованы и их можно хранить в глобальном scope ключей. А как же быть с ключем «0», разве он не будет в хранилище храниться как «facebook.com.0» чтобы хоть как-то различать «0» от различных сервисов. Ответ: он тоже зашифровав, расшифровка «0» ключа происходит на клиенте web ui хранилища ключей специальным паролем.
Вопрос: зачем эта вся возня с ключами, если можно просто вот тем паролем, per service, которым мы расшифровываем «0» ключ напрямую расшифровывать все данные сервиса. Дело в том, что это создает один большой пароль на весь профиль. А например расшарить фотку с друзьями - поделиться ключами для encrypted value фотки. Убрать права доступа, что случается реже - создать новый обьект, новый ключ, перешифровать и раздать заново всем друзьям.
Что если хранилище и сервис в сговоре? Ставим еще хранилище, которое рассматривает первое хранилище как сервис. И так до того уровня, пока мы не будем считать что сговор маловероятен, а одновременный координированый перехват запросов слишком сложен
Вот такая норкомания. Я пошел обедать.
