Зачем вам аж два девайса с одними и теми же паролями? Протокол подразумевает смену паролей на собеседниках при каждом сообщении. Если третий(еще один PSD) девайс не участвует в общении, то у него ключи устареют.
Вообще, база дублируется на компьютере(вашем домашнем) и будет совместима с KeePass.
Так что проще в случае утери девайса просто купить новый и записать пароли на него снова. И при этом можно быть уверенным, что со старого(украденного) не достанут пароли даже если узнают ваш мастер-пароль. В том и суть же.
>Флешка со сканером отпечатков пальцев и с эмуляцией клавиатуры
оно есть. Вы имеете ввиду биометрическую аутентификацию? Есть девайсы для этого. Но это не поможет вам авторизоваться в сервисе, принимающем только символьные пароли.
Самый простой пример, как я часто уже писал, это шифрованный диск с операционной системой. Я не уверен, что там можно вход по ключам сделать, но даже если можно, то утеря ключа будет очень неприятной.
Я не знаю как именно работает ваше соединение, но в описании было написано >стандартный ввод Bluetooth
Вот первая более-менее адекватная статья последовательности действий в Kali, чтобы поломать bluetooth протокол клавиатуры. null-byte.wonderhowto.com/how-to/hack-bluetooth-part-1-terms-technologies-security-0163977
Я не гарантирую ее полную верность, но точно помню отличные старые лекции, когда ломали клавиатуры по 30-ти нажатиям. Надо понимать, что шифрование не изменилось.
1. Да, естественно. Моно только запустить надо. А оно ставится очень просто(на дебиан и убунту вообще с ходу)
2. Два свистка? Имеется ввиду 2 PSD? Это небезопасно. Любая система, работающая с двумя свистками будет взламываема при краже одного свистка и чтения памяти с него.
Переходник на микро usb и сами думаем. Но вообще они продаются повсеместно, а нужны не всем. Зависит от того как использовать устройство.
Да, я даже писал про кейлоггер.
Пароль вводится в обычном виде, будто это клавиатура, но удобно для пользователя(без, непосредственно, ввода).
Это будет работать с любым сервисом, принимающим символьные пароли. И сервис даже не должен знать о том кто вводит пароль
Вы же знаете как работает встроенное шифрование bluetooth, да?
Спарринг можно подделать за 7 секунд(при 6-символьном пароле), а пароли читать вообще без этого.
Кстати, уже придумал как вам малварь на комп закинуть с такой системой
1) получаем MITM доступ
2) кидаем набор управляющих символов для открытия блокнота, написания скрипта и сохранения его
3) запускаем с нужными правами
4) получаем бэкдор или_что_нам_там_нужно
USB-hid поддерживается почти везде. На текущий момент это самый универсальный способ ввода паролей без установки софта.
Android, IPhone, WinPhone поддерживают usb-hid. Кто-то усложняет эксплуатацию универсальных переходников за счет инновационных разъемов, но суть одинакова.
Кстати, никто не задал вопрос «Как ввести пароль на сам телефон, с которого он отправляется?». Я предусмотрел и это, добавив задержку ввода пароля.
Пинпады.
Там короткие цифровые пароли. Их легко вводить.
Пароль на терминале в интернет-кафе.
Если часто приходится с этим иметь дело, то можно один раз дома задать VID и PID клавиатуры в интернет кафе.
Ну, не стоит забывать, что код открыт. Он был открыт и будет открыт, потому что он работает с чувствительными для пользователей данными.
«Прилет троянца» будет огромным ударом по репутации.
Да и форки никто не отменял.
Пока что у нас закрыт только код на сам девайс(PSD). С него сделать чего-то плохого проблематично, а уж слить пароли еще сложнее.
При этом, планируется его открыть в будущем.
Я не очень понимаю вектор, который вы рассматриваете. Предполагается, что PSD начнет вводить в режиме клавиатуры непотребщину уровня скриптов для создания бэкдора? Это очень сложно реализовать незаметно и надо быть уверенным в том, какая ОС используется.
Но все это можно обсудить, мы не mozilla и гораздо проще в коммуникации.
Окей. Вектор:
1) перехватывать весь трафик
2) Украсть устройство
3) достать ключ дешифрования с него(для дешифрования ключ будет храниться на девайсе)
4) расшифровать весь трафик, что шел ранее
5) соединить все посланные password_part_2 со всеми соответствующими password_part_1 на устройстве
В итоге получим все пароли, которые мы когда либо вводили.
Собственно, смена ключей на каждом пакете и нужна, чтобы расшифровать можно было только следующий пакет. Для предыдущего пакета паролей не существует.
Diffie-Hellman, к тому же, не подходит в качестве пост-квантовой системы.
Еще можно попробовать атаки на спаривание устройств. Например, попробовать спарить фейковое устройство раньше и перехватывать password_part_2 с уже известным ключом.
1. Мы еще рассматриваем альтернативы. Возможно, будет и то, и то.
2. Да, достаточно добавить еще один тип пакета
3. Еще удобнее. Есть политики хранения пароля. В идеале, пароль вводится один раз в день(или реже). Можно сделать, чтобы пароль сбрасывался каждые 30 минут. Обычно, подключение к базе висит в сервисе(не кушает заряда совсем).
4. А зачем? Это усложнит подключение устройства. Или это способ решить 2-й пункт?
5. Да, есть очень мелкие и удобные переходники. Андроид ведет себя с ними хорошо, все работает отлично, я проверял.
6. Я не думаю, что это усложнит задачу хакеру
7. Одноразовые пароли очень просты. У гугла это 6 цифр. Их ввести просто и быстро. PSD же позволяет автоматически вводить пароли, которые заняли бы много энергии и концентрации.
Работа со специализированными крипточипами, как это делают токены аутентификации, возможно, тоже будет. Как за счёт кастомных прошивок, так и за счёт выпуска специальных версий устройства. Всё зависит от степени интереса сообщества к девайсу.
Я думал, что речь идет о брелках с одноразовыми паролями.
В принципе, можно реализовать этот функционал. Но там достаточно простые пароли высылаются(6 цифр) и их просто набрать.
А вот пароли с кучей символов и в разных регистрах набирать проблематично.
1. Я отсылаю обратно старый HBtKey, чтобы подтвердить, что пароль действительно был введен успешно. Вы правы, что менять его каждый раз нет необходимости, но это не уменьшает безопасность системы и мы имеем что отправлять как респонс.
2. Выше я уже отвечал, но уже после вашего комментария. Там есть способ разрешения таких проблем
>связь между устройствами рвётся
да, есть такой кейс. Именно для этого на телефоне предусмотрен таймаут ответа. Если он превышен, то вылезает занятное окошко, описывающее ситуацию и предлагающее пользователю прокрутить ключи или оставить как есть. Прокрутить надо, если пароль был введен.
К сожалению, я не могу описать все в одной статье.
К сожалению, я не могу решать все задачи сразу. Сейчас я решаю лишь проблему ввода символьных паролей.
Я полагаю, что места где используются TOTP / HOTP для двух-факторной авторизации уже имеют своих специалистов по безопасности, которые не особо будут довольны подобной самодеятельностью.
>проблема доставки первых ключей BtKey[i] и HBtKey[i]
Первая картинка(шаг 1)
Первые ключи это BtKey0 и HBtKey0. Они записываются самым безопасным возможным способом — общим распространителем.
То есть они попадают на оба девайса при записи туда баз.
>6 пункт генерирует, а отправляет аж на 9 пункте
Так и задумано. Ввод производится относительно долгое время(секунд 5 для длинных паролей) и надо предотвратить возможность выдернуть устройство до смены паролей на новые. Поэтому, пароли надо заменить как можно раньше и стереть старые. Но мы отсылаем хэш старого пароля(HBtKey) обратно. Если мы его сотрем, то не сможем потом сгенерировать ответ. Поэтому генерируем сразу и удаляем пароли.
>связь между устройствами рвётся
да, есть такой кейс. Именно для этого на телефоне предусмотрен таймаут ответа. Если он превышен, то вылезает занятное окошко, описывающее ситуацию и предлагающее пользователю прокрутить ключи или оставить как есть. Прокрутить надо, если пароль был введен.
К сожалению, я не могу описать все в одной статье. Но это хорошее и логичное замечание!
[del]
Извиняюсь, я забыл, что удалять комментарии нельзя. А хабр перестал давать возможность отвечать в одном из комментариев, решил проверить, что могу еще постить
Я бы не назвал это самодельной криптографией. Используется AES256. Его я не трогаю и уважаю. Но ключи для него я меняю часто.
По факту, нового тут только изменение ключей в каждом пакете. То, что начальные пароли шифрования задаются с компьютера, это лишь один из простейших способов передачи ключей собеседникам. Обычно эта часть и является проблемной. Но я это делаю напрямую и в защищенной среде. Это не новый подход(к сожалению, не смог с ходу загуглить. Но как пример — передать пароли при личной встрече Алисы и Боба)
Единственное, что ново это смена ключей. Так как передаются лишь новые ключи, то никаких взаимосвязей с текущим шифрованным сообщением быть не может. Это всего-лишь кусок данных
Зависит от способов использования. Например, если вы работаете за одним рабочим местом, то провести этот набор действий необходимо будет лишь один раз по приходу на него. Если вы администрируете что-либо, то вводить пароли приходится разные и по несколько раз.
Для ssh есть, конечно, ключи. Но не из под рута же работать на машинах.
Предполагается, что телефон просто лежит на столе, а на телефоне запущено приложение(оно имеет сервис, который совсем не тратит энергии).
В сервисе уже разблокированная база(повторно мастер-пароль вводить нет необходимости) и надо лишь совершить долгое нажатие на нужный пароль из списка.
У вас интересная идея, но она будет очень зависеть от того где находится компьютер и его usb-порт. Но даже если предположить, что протянут удобный провод, то все равно придется запоминать комбинации для всех сервисов.
Так же не стоит забывать, что люди очень плохи в генерации случайных событий. И однозначно будут частоиспользуемые комбинации.
Это значительно упростит перебор. А еще не стоит забывать о камерах наблюдения и разводах на стекле.
Я всегда исхожу из предположения, что устройство могут украсть, поэтому соль известна злоумышленнику.
У меня очень серьезные опасения по поводу безопасности протокола передачи данных. В моем случае первые пароли задаются по гарантированно шифрованному каналу. Здесь, в лучшем случае, используется ассиметричное шифрование. А, скорее всего, plain text.
На сайте ни слова о безопасности, что настораживает.
Я бы посоветовал послушать bluetooth трафик. И если там plain text, то либо заменить систему, либо держать ее в тайне.
Вообще, база дублируется на компьютере(вашем домашнем) и будет совместима с KeePass.
Так что проще в случае утери девайса просто купить новый и записать пароли на него снова. И при этом можно быть уверенным, что со старого(украденного) не достанут пароли даже если узнают ваш мастер-пароль. В том и суть же.
оно есть. Вы имеете ввиду биометрическую аутентификацию? Есть девайсы для этого. Но это не поможет вам авторизоваться в сервисе, принимающем только символьные пароли.
Самый простой пример, как я часто уже писал, это шифрованный диск с операционной системой. Я не уверен, что там можно вход по ключам сделать, но даже если можно, то утеря ключа будет очень неприятной.
Вот первая более-менее адекватная статья последовательности действий в Kali, чтобы поломать bluetooth протокол клавиатуры.
null-byte.wonderhowto.com/how-to/hack-bluetooth-part-1-terms-technologies-security-0163977
Я не гарантирую ее полную верность, но точно помню отличные старые лекции, когда ломали клавиатуры по 30-ти нажатиям. Надо понимать, что шифрование не изменилось.
2. Два свистка? Имеется ввиду 2 PSD? Это небезопасно. Любая система, работающая с двумя свистками будет взламываема при краже одного свистка и чтения памяти с него.
Переходник на микро usb и сами думаем. Но вообще они продаются повсеместно, а нужны не всем. Зависит от того как использовать устройство.
Пароль вводится в обычном виде, будто это клавиатура, но удобно для пользователя(без, непосредственно, ввода).
Это будет работать с любым сервисом, принимающим символьные пароли. И сервис даже не должен знать о том кто вводит пароль
Спарринг можно подделать за 7 секунд(при 6-символьном пароле), а пароли читать вообще без этого.
2) кидаем набор управляющих символов для открытия блокнота, написания скрипта и сохранения его
3) запускаем с нужными правами
4) получаем бэкдор или_что_нам_там_нужно
Android, IPhone, WinPhone поддерживают usb-hid. Кто-то усложняет эксплуатацию универсальных переходников за счет инновационных разъемов, но суть одинакова.
Кстати, никто не задал вопрос «Как ввести пароль на сам телефон, с которого он отправляется?». Я предусмотрел и это, добавив задержку ввода пароля.
Пинпады.
Там короткие цифровые пароли. Их легко вводить.
Пароль на терминале в интернет-кафе.
Если часто приходится с этим иметь дело, то можно один раз дома задать VID и PID клавиатуры в интернет кафе.
«Прилет троянца» будет огромным ударом по репутации.
Да и форки никто не отменял.
Пока что у нас закрыт только код на сам девайс(PSD). С него сделать чего-то плохого проблематично, а уж слить пароли еще сложнее.
При этом, планируется его открыть в будущем.
Я не очень понимаю вектор, который вы рассматриваете. Предполагается, что PSD начнет вводить в режиме клавиатуры непотребщину уровня скриптов для создания бэкдора? Это очень сложно реализовать незаметно и надо быть уверенным в том, какая ОС используется.
Но все это можно обсудить, мы не mozilla и гораздо проще в коммуникации.
1) перехватывать весь трафик
2) Украсть устройство
3) достать ключ дешифрования с него(для дешифрования ключ будет храниться на девайсе)
4) расшифровать весь трафик, что шел ранее
5) соединить все посланные password_part_2 со всеми соответствующими password_part_1 на устройстве
В итоге получим все пароли, которые мы когда либо вводили.
Собственно, смена ключей на каждом пакете и нужна, чтобы расшифровать можно было только следующий пакет. Для предыдущего пакета паролей не существует.
Diffie-Hellman, к тому же, не подходит в качестве пост-квантовой системы.
Еще можно попробовать атаки на спаривание устройств. Например, попробовать спарить фейковое устройство раньше и перехватывать password_part_2 с уже известным ключом.
2. Да, достаточно добавить еще один тип пакета
3. Еще удобнее. Есть политики хранения пароля. В идеале, пароль вводится один раз в день(или реже). Можно сделать, чтобы пароль сбрасывался каждые 30 минут. Обычно, подключение к базе висит в сервисе(не кушает заряда совсем).
4. А зачем? Это усложнит подключение устройства. Или это способ решить 2-й пункт?
5. Да, есть очень мелкие и удобные переходники. Андроид ведет себя с ними хорошо, все работает отлично, я проверял.
6. Я не думаю, что это усложнит задачу хакеру
7. Одноразовые пароли очень просты. У гугла это 6 цифр. Их ввести просто и быстро. PSD же позволяет автоматически вводить пароли, которые заняли бы много энергии и концентрации.
В принципе, можно реализовать этот функционал. Но там достаточно простые пароли высылаются(6 цифр) и их просто набрать.
А вот пароли с кучей символов и в разных регистрах набирать проблематично.
2. Выше я уже отвечал, но уже после вашего комментария. Там есть способ разрешения таких проблем
>связь между устройствами рвётся
да, есть такой кейс. Именно для этого на телефоне предусмотрен таймаут ответа. Если он превышен, то вылезает занятное окошко, описывающее ситуацию и предлагающее пользователю прокрутить ключи или оставить как есть. Прокрутить надо, если пароль был введен.
К сожалению, я не могу описать все в одной статье.
Я полагаю, что места где используются TOTP / HOTP для двух-факторной авторизации уже имеют своих специалистов по безопасности, которые не особо будут довольны подобной самодеятельностью.
Первая картинка(шаг 1)
Первые ключи это BtKey0 и HBtKey0. Они записываются самым безопасным возможным способом — общим распространителем.
То есть они попадают на оба девайса при записи туда баз.
>6 пункт генерирует, а отправляет аж на 9 пункте
Так и задумано. Ввод производится относительно долгое время(секунд 5 для длинных паролей) и надо предотвратить возможность выдернуть устройство до смены паролей на новые. Поэтому, пароли надо заменить как можно раньше и стереть старые. Но мы отсылаем хэш старого пароля(HBtKey) обратно. Если мы его сотрем, то не сможем потом сгенерировать ответ. Поэтому генерируем сразу и удаляем пароли.
>связь между устройствами рвётся
да, есть такой кейс. Именно для этого на телефоне предусмотрен таймаут ответа. Если он превышен, то вылезает занятное окошко, описывающее ситуацию и предлагающее пользователю прокрутить ключи или оставить как есть. Прокрутить надо, если пароль был введен.
К сожалению, я не могу описать все в одной статье. Но это хорошее и логичное замечание!
Извиняюсь, я забыл, что удалять комментарии нельзя. А хабр перестал давать возможность отвечать в одном из комментариев, решил проверить, что могу еще постить
По факту, нового тут только изменение ключей в каждом пакете. То, что начальные пароли шифрования задаются с компьютера, это лишь один из простейших способов передачи ключей собеседникам. Обычно эта часть и является проблемной. Но я это делаю напрямую и в защищенной среде. Это не новый подход(к сожалению, не смог с ходу загуглить. Но как пример — передать пароли при личной встрече Алисы и Боба)
Единственное, что ново это смена ключей. Так как передаются лишь новые ключи, то никаких взаимосвязей с текущим шифрованным сообщением быть не может. Это всего-лишь кусок данных
Для ssh есть, конечно, ключи. Но не из под рута же работать на машинах.
Предполагается, что телефон просто лежит на столе, а на телефоне запущено приложение(оно имеет сервис, который совсем не тратит энергии).
В сервисе уже разблокированная база(повторно мастер-пароль вводить нет необходимости) и надо лишь совершить долгое нажатие на нужный пароль из списка.
У вас интересная идея, но она будет очень зависеть от того где находится компьютер и его usb-порт. Но даже если предположить, что протянут удобный провод, то все равно придется запоминать комбинации для всех сервисов.
Так же не стоит забывать, что люди очень плохи в генерации случайных событий. И однозначно будут частоиспользуемые комбинации.
Это значительно упростит перебор. А еще не стоит забывать о камерах наблюдения и разводах на стекле.
Я всегда исхожу из предположения, что устройство могут украсть, поэтому соль известна злоумышленнику.
На сайте ни слова о безопасности, что настораживает.
Я бы посоветовал послушать bluetooth трафик. И если там plain text, то либо заменить систему, либо держать ее в тайне.