Якобы заявляется что ключ никогда не покидает устройство, под устройством подразумевается защищенный чип TPM и подобные.
Но! При этом предусмотрена синхронизация между девайсами, т.е. ключи из одного такого устройства таки можно скопировать на другое. И якобы ключи передаются в зашифрованном виде — второе устройство передает первому свой публичный ключ, первое устройство криптует и передает в криптованном виде — прочесть сможет только второе устройство в своих внутрях, т.к. закрытый ключ никогда не покидает микросхему.
Так вот — фатальный недостаток — синхронизация происходит по закрытым протоколам и только между девайсами одного вендора.
Так же нет прозрачности — не ясно что мешает мне как взломщику реверснуть протокол и подставить свое вирт. устройство, выполнив синхронизацию и заполучив ключи. Т.е. в таком важном вопросе нет прозрачности.
Здравствуйте, Shmj, Вы писали:
S>Так же нет прозрачности — не ясно что мешает мне как взломщику реверснуть протокол и подставить свое вирт. устройство, выполнив синхронизацию и заполучив ключи. Т.е. в таком важном вопросе нет прозрачности.
то что ты описал — это классический протокол обмена закрытым ключем (например диффи-хеллман), при корректной реализации проблем нет, кроме mitm атаки.
Здравствуйте, mike_rs, Вы писали:
S>>Так же нет прозрачности — не ясно что мешает мне как взломщику реверснуть протокол и подставить свое вирт. устройство, выполнив синхронизацию и заполучив ключи. Т.е. в таком важном вопросе нет прозрачности.
_>то что ты описал — это классический протокол обмена закрытым ключем (например диффи-хеллман), при корректной реализации проблем нет, кроме mitm атаки.
Тут дело в другом — все закрыто. Один девайс передает некому другому — а откуда я как пользователь знаю куда именно оно передается?
S>>Так же нет прозрачности — не ясно что мешает мне как взломщику реверснуть протокол и подставить свое вирт. устройство, выполнив синхронизацию и заполучив ключи. Т.е. в таком важном вопросе нет прозрачности. _>то что ты описал — это классический протокол обмена закрытым ключем (например диффи-хеллман), при корректной реализации проблем нет, кроме mitm атаки.
Ну в смысле, это и есть проблема, которую они должны решить.
Я думаю что в каждом ихнем девайсе зашит уникальный сертификат, подписанный ихним CA, и они не просто публичными ключиками обмениваются, но и проверяют что эти ключики — подписаны этим общим для них CA. В противном случае вся эта крипта не имеет никакого смысла.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, mike_rs, Вы писали:
_>то что ты описал — это классический протокол обмена закрытым ключем (например диффи-хеллман), при корректной реализации проблем нет, кроме mitm атаки.
Раз уж там устройства одного производителя, то скорей всего там еще и подпись при выработке общего ключа с верификацией через предпрошитый паблик, поэтому mitm вряд ли возможен.
Здравствуйте, pva, Вы писали:
_>>то что ты описал — это классический протокол обмена закрытым ключем (например диффи-хеллман), при корректной реализации проблем нет, кроме mitm атаки. pva>Раз уж там устройства одного производителя, то скорей всего там еще и подпись при выработке общего ключа с верификацией через предпрошитый паблик, поэтому mitm вряд ли возможен.
Ну если бы это все гарантировалось открытыми протоколами — то да. А так — мы не знаем что там реально.
S>Так же нет прозрачности — не ясно что мешает мне как взломщику реверснуть протокол и подставить свое вирт. устройство, выполнив синхронизацию и заполучив ключи. Т.е. в таком важном вопросе нет прозрачности.
Криптография помешает. Не зная пароля от айклауда ничего ты не заполучишь.
Здравствуйте, Константин Б., Вы писали:
КБ>Криптография помешает. Не зная пароля от айклауда ничего ты не заполучишь.
А откуда вы это знаете? Откуда чип знает ваш пароль? Вот, допустим, некий Вася реверснул протокол и из своей программы вызывает системный API, который предназначен для переноса ключей в другое устройство. Но вместо другого устройства — переносит их в свое вирт. устройство. Откуда мы знаем что такой варианте не возможен, если протоколы закрыты и проверить что там есть защита от такого сценария (и какая именно) — мы не можем?
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, Константин Б., Вы писали:
КБ>>Криптография помешает. Не зная пароля от айклауда ничего ты не заполучишь.
S>А откуда вы это знаете? Откуда чип знает ваш пароль?
Чип его знает из того что пользователь его вводит.
S>Вот, допустим, некий Вася реверснул протокол и из своей программы вызывает системный API, который предназначен для переноса ключей в другое устройство. Но вместо другого устройства — переносит их в свое вирт. устройство.
— Есть хранилище ключей из которого нельзя ничего прочитать не введя пароль
— Даже введя пароль — прочитать ключи из хранилища может только операционная система
— Есть апи для загрузки ключей в айклауд в зашифрованом виде которое требует аутентификации паролем
— Есть апи для загрузки ключей из айклауда которое 1) требует аутентификации паролем 2) требует пароля чтобы ключи расшифровать
В каком из этих мест может подлезть Вася не знающий пароль?
Здравствуйте, Константин Б., Вы писали:
КБ>- Есть хранилище ключей из которого нельзя ничего прочитать не введя пароль КБ>- Даже введя пароль — прочитать ключи из хранилища может только операционная система КБ>- Есть апи для загрузки ключей в айклауд в зашифрованом виде которое требует аутентификации паролем КБ>- Есть апи для загрузки ключей из айклауда которое 1) требует аутентификации паролем 2) требует пароля чтобы ключи расшифровать
