Хэшировать платежку можно и на токене, хэшировать какой-нибудь скан документа — малореально. В моем понимании, основное преимущество это отсутствие необходимости устанавливать сертифицированное криптосредство на рабочую станцию клиента. Это особенно актуально для «тетушек из бухгалтерии».
Генерация ключевых пар, а также выработка сессионных ключей должна производится в смарткарте. Это может быть TPM или отторгаемый носитель и в этом основная идея Google. В случае наличия трояна на устройстве, троян конечно сможет организовать несанкционированое подключение с этого устройства к серверу, используя возможности TPM или в момент когда подключен отторгаемый носитель, но украсть ключи он не сможет.
Кроме того, организация MITM после первичного обмена открытыми ключами невозможна.
Если это его заинтересует, то только в качестве PR. Цель использования шифрования на МЕГЕ защитить хостинг от правообладателей. Как бы это не было реализовано на МЕГЕ, оно свою задачу выполнят. Безопасность информации их вряд ли волнует.
Однако подобный подход может быть эффективен при организации защищенного обмена информацией на различных публичных чатах и сервисах электронной почты. Интересно было бы посмотреть такие решения.
Да, защитить можно только тех, кто этого хочет. Однако в системах ДБО банк вынужден обеспечивать безопасность клиентов, и как вы верно заметили удобство используемых механизмов безопасности играет далеко не последнюю роль.
Да, возможно «читаем» было бы вернее.
Многие мобильные браузеры используют оптимизацию трафика на своих серверах. Однако, или не трогают https (Amazon Silk) или предупреждают (Opera Mini).
Если информация где-то присутствует в открытом виде, рано или поздно, она станет достоянием общественности.
p.s. https прокси не имеет доступа к передаваемому содержимому, а передает зашифрованные данные как есть.
Это верно? «Портативный накопитель информации по п.17, отличающийся тем, что аппаратный ускоритель шифрации выполнен обеспечивающим шифрование данных в соответствии с взятыми за основу симметричными алгоритмами шифрования ГОСТ 28147-89 с измененной длиной ключа до 32 бит.»
Не понятна логика…
Вы собираетесь проводить сертификацию устройство в ФСБ? Если да, изменение алгоритмов не пройдет. Если нет, зачем городить огород с ГОСТ если есть аппаратные решения с AES. Решения эти в разы производительней и дешевле. Если вы боитесь «закладок» в реализации AES алгоритмов, то ваше решение ни чего не меняет. Во первых, почему мы должны доверять вашей реализации? Во вторых, никто не отменял возможности производителя чипов реализовать «закладки» позволяющей извлечь содержимое вашего микропроцессора.
Так же хотелось бы понять юридические аспекты. Разработка средств защиты информации требует наличия лицензии ФСТЭК, а разработка средств шифрования лицензии ФСБ. Как у вас с этими вопросами?
Думаю, проблема с позиционирование этого решения в массах. Короче PR не отработал. Я к тому, что это решение не сильно отличается от того, что есть сейчас со сбором и таргетированием рекламы. Просто это надо как-то донести конечному пользователю. :)
Кроме того, организация MITM после первичного обмена открытыми ключами невозможна.
Однако подобный подход может быть эффективен при организации защищенного обмена информацией на различных публичных чатах и сервисах электронной почты. Интересно было бы посмотреть такие решения.
Многие мобильные браузеры используют оптимизацию трафика на своих серверах. Однако, или не трогают https (Amazon Silk) или предупреждают (Opera Mini).
p.s. https прокси не имеет доступа к передаваемому содержимому, а передает зашифрованные данные как есть.
Это верно? «Портативный накопитель информации по п.17, отличающийся тем, что аппаратный ускоритель шифрации выполнен обеспечивающим шифрование данных в соответствии с взятыми за основу симметричными алгоритмами шифрования ГОСТ 28147-89 с измененной длиной ключа до 32 бит.»
Вы собираетесь проводить сертификацию устройство в ФСБ? Если да, изменение алгоритмов не пройдет. Если нет, зачем городить огород с ГОСТ если есть аппаратные решения с AES. Решения эти в разы производительней и дешевле. Если вы боитесь «закладок» в реализации AES алгоритмов, то ваше решение ни чего не меняет. Во первых, почему мы должны доверять вашей реализации? Во вторых, никто не отменял возможности производителя чипов реализовать «закладки» позволяющей извлечь содержимое вашего микропроцессора.
Так же хотелось бы понять юридические аспекты. Разработка средств защиты информации требует наличия лицензии ФСТЭК, а разработка средств шифрования лицензии ФСБ. Как у вас с этими вопросами?