В OpenSSH добавлена двухфакторная аутентификация

ты слишком узко воспринимаешь слово канал.

позицию я твою, конечно, понял, может ты и прав, а может и нет — но в любом случае, спор об определениях (что считать фактором, что считать каналом), а не о технической сути

Все же, положа руку на сердце, не скажу что ты меня убедил. На мой взгляд, в приведенной мной статье написано не совсем то, о чем ты говоришь. Там в качестве ПРИМЕРА двухфакторной авторизации приведен случай с логином-паролем + СМС, но то что этот пример описывает двухфакторную не означает что другие примеры не описывают, например с файлом-ключом + паролем.

Еще раз, такая «защита» есть в любом нормальном мк, даже в китайских STC и nuvoton. Ничего инновационного и необычного тут нет.

Ну там в качестве ПРИМЕРА не поленились перечислить ВСЕ варианты одноразовых паролей. Включая даже карту предварительно сгенереных паролей, которую я уже в жизни несколько лет как не видел, это же еще эпоха телефонной авторизации платежей.

А простой вариант ключ и (логин)пароль почему то не указали. Или пинкод и банковская карточка или (ру)токен и его пинкод. Потому что есть точка, в которой оба фактора объединяются в один чуть более сложный.

например с файлом-ключом + паролем.

Потому что не тут двух факторов. ;) И в случае с карточкой + пинкод в банкомате тоже нет. И в случае с карточкой и дополнительным cvv кодом тоже нет. Это все дополнительная защита одного фактора.

В этом смысле будем откровенны, двухфакторная авторизация с телефона по смске, которая приходит на этот же телефон, это уже вырожденный случай, потому что появляется точка, в которой доступен перехват сразу двух факторов. В нормальной двухфакторной системе такой точки быть не должно.

это была копия. её засунули в банкомат где-то в Германии и сняли деньги со счёта. таких случаев навалом.

Смысл аппаратных ключей в том что без физического доступа к ключу нет шансов на его копирование.

Кроме того в нормальном ключе хардварном ключе не просто сохраняется криптографический ключ, но и соответствующие ему криптографические алгоритмы.

Тоесть без физического доступа к ключу злоумышленник не только не получит доступа к криптографическим ключам, но и не будет иметь понятия о используемых в системе криптографических алгоритмах.

появляется точка, в которой доступен перехват сразу двух факторов. В нормальной двухфакторной системе такой точки быть не должно

ну вот эта мысль, которую ты отстаиваешь. На мой взгляд (сразу предупреждаю, я не сведущ в вопросе, так что на мой взгляд из деревни), ты это сам выдумал. В статье было написано «N способов аутентификации» то-есть N способов доказать что ты действительно тот, за кого себя выдаешь. Про то, что такие способы обязательно не должны сводиться к общему базису там нет.

Ну там в качестве ПРИМЕРА не поленились перечислить ВСЕ варианты одноразовых паролей ... А простой вариант ключ и (логин)пароль почему то не указали

это все равно ничего не доказывает, только косвенно намекает )

это была копия. её засунули в банкомат где-то в Германии и сняли деньги со счёта

ну это с твоих слов, а тебе рассказали

таких случаев навалом.

не слышал ни одного. пруфов тоже не увидел. рабочего способа снять копию с карты без инсайдерской информации банка тоже не увидел. не уверую пока персты не вложу

Термин «нормальный» применительно к микроконтроллерам мне не знаком. Но вы явно не в курсе того о чем рассуждать пытаетесь. Вам не только нужно иметь память которая не считывается извне, вам нужно уметь отключать загрузку контроллера с внешней шины, запрещать jtag и т.п. Вы хоть один контроллер толком изучали?

Термин «нормальный» применительно к микроконтроллерам мне не знаком.

Тот, который выпущен партией больше 500 штук на MPW и продается.

Защита прошивки от копирования для мк сейчас это базовый функционал, который есть везде: avr, msp430, stm32, 8051 (stc, at89, nuvoton). Это из того, что ковырял. При этом у STC вообще возможности ридбэка не заложено принципиально. Загрузку с внешней шины памяти практически никто не делает, только мамонты в LON-устройствах для автоматизации (Только там видел, больше нигде). ESP8266 разве что одно время грузился с внешней SPI, но теперь есть вариант с SPI в одном корпусе с ESP8266. Но там не критично, ибо все конечные устройства привязаны по серийнику к облаку. Можно копировать прошивку сколько угодно, без облака оно бесполезно. Во всех остальных случаях, если нет защиты от ридбэка китайский клон появится не через 3-4 месяца после запуска устройства, а через неделю.

Вам не только нужно иметь память которая не считывается извне, вам нужно уметь отключать загрузку контроллера с внешней шины, запрещать jtag и т.п

Разупорись, как правило это делается либо одним фьюз битом, для удобства, либо несколькими. И включенный JTAG не гарантирует возможности чтения прошивки. См. nrf51822

Вы хоть один контроллер толком изучали?

Нет, это по ходу Вы, батенька вообще от индустрии далеко живете.

В статье было написано «N способов аутентификации» то-есть N способов доказать что ты действительно тот, за кого себя выдаешь.

Это одно и тоже. N способов только тогда N, когда они полностью независимы. Например, печать и подпись. Или подпись директора и бухгалтера. А если директор подпишется дважды или печать будет из двух частей но в одних руках, это будет все та же одна подпись директора или одна печать.

Когда тебе надо тысячу и раздать работникам - проще заплатить чем пилить самому.

Там Ki был короткий и без проверок на подбор. Пофикшено лет десять назад.

Плохой перевод. Не шифрует и не AES и не номер сессии.

Генерирует на основе закрытого ключа для эллиптической кривой, идентификатора Relying Party (сервера на который идентифицируешься, для браузера - fqdn), подписывает челлендж от сервера для аутентификации.

как извечь ключ из банковской карты

Зачем ломиться в запертую дверь, если окно открыто?

Это что-то новое. Последняя реализация, которую я имплементил выглядела как-то так:

#include <arch/antares.h>
#include <avr/eeprom.h>
#include <string.h>
#include <util/crc16.h>
#include <skeleton.h>
#include "aes.h"


/* 8hz timer is recommended */
uint16_t g_timestamp_low;
uint8_t g_timestamp_high;

static uint8_t otps_generated;

#define YUBIKEY_MODHEX_MAP "cbdefghijklnrtuv"
const char trans[] = YUBIKEY_MODHEX_MAP;

void yubikey_modhex_encode (char *dst, const char *src, size_t srcSize)
{
  while (srcSize--)
    {
      *dst++ = trans[(*src >> 4) & 0xf];
      *dst++ = trans[*src++ & 0xf];
    }

  *dst = '\0';
}


inline uint16_t yubi_crc16_update(uint16_t crc, uint8_t a)
{
    int i;

    crc ^= a;
    for (i = 0; i < 8; ++i)
    {
        if (crc & 1)
            crc = (crc >> 1) ^ 0x8408;
        else
            crc = (crc >> 1);
    }

    return crc;
}


void skeleton_send_yubi_token(struct key_yubikey *conf)
{
	int len, i;
	char buf[64];
	struct yubikey_secret_token tok;
	char *ptr;
	uint16_t crc = 0x5af0;
	aes128_ctx_t ctx;


	len = min_t(int, 2 * YUBIKEY_ID_LEN, strlen(conf->pub_string));
	memcpy(buf, conf->pub_string, len);
	memcpy(tok.secret, conf->secret, YUBIKEY_ID_LEN);

	cli();
	tok.timestamp_high = g_timestamp_high;
	tok.timestamp_low  = g_timestamp_low;
	sei();

	tok.insert_count = g_eeprom_conf.insertcount;
	tok.otps = otps_generated++;

	tok.random = rand(); //Fair dice roll

	ptr = (char *) &tok;
	for (i=0; i < sizeof(struct yubikey_secret_token) - sizeof(uint16_t); i++) {
		crc = yubi_crc16_update(crc, ptr[i]);
	}

	tok.crc = crc;

	aes128_init(conf->aes_key, &ctx);
	aes128_enc(&tok, &ctx);

	yubikey_modhex_encode(&buf[len], &tok, sizeof(tok));
	skeleton_type_message(buf);
}

void update_rgb();
ISR(TIMER1_OVF_vect)
{
	if (++g_timestamp_low == 0) {
		g_timestamp_high++;
	}
	//update_rgb();

}

ANTARES_INIT_LOW(timer_init)
{
	TCCR1A = 0;
	TCCR1B = 0;
	ICR1 = 1470; /* ~8Hz at 12Mhz clock */
	TCCR1A = (1<<WGM11);
	TCCR1B = (1 << WGM13) | (1<<WGM12) | 0x5; // /1024
#ifdef TIMSK
	TIMSK = 1<<TOIE1;
#else
	TIMSK1 = 1<<TOIE1;
#endif

}

По сути берем секретную строку, количество втыканий, значение таймера, шифруем AES одним блоком, потом транслируем в modhex и печатаем имитируя клавиатуру.

Кому надо, вот моя старая реализация этих токенов: https://git.ncrmnt.org/firmwares/SkeletonKey/

Ну и я сомневаюсь, что кто-то в здравом уме и трезвой памяти будет реверсить скомунизженный токен.

Это смотря что на нем висит. А если кошелек с битками на миллиард?

Паяльник таки будет эффективнее ;)

Охрана может помешать. А так ключик на пять минут тиснул и вернул.

Ну я смотрю вы теоретик, в реальной жизни куча «нормальных» контроллеров ничего этого не имеют. Почитайте что такое защита памяти в смарт картах и как она организована, ну просто чтобы потом больших глаз не делать когда из ваших «защищенных» контроллеров начинают данные копировать. А «ковырять» можете что угодно, как на опыт только ссылаться не стоит.

Ссылки в студию, практик.

Ты об этом?

Мой клон YubiKey с блэкджеком: SkeletonKey-R1

Как только отлажу фирмварю - выложу все в опенсорс и сделаю детальное описание.

Получил ли проект развитие? Мне было бы интересно поковыряться.

Он самый. Просто запилил себе несколько токенов, и пользуюсь для своих нужд. В массы выводить не думаю. Ну, еще корпус на 3д-принтере распечатал под него. Если обитаешь в мск, могу отсыпать тебе токен в обмен за годный кофеин и патчи ;)

Не, я от Москвы далеко обитаю. Давай лучше обещанное

выложу все в опенсорс и сделаю детальное описание

пользуюсь для своих нужд

Причем желательно с описанием сценариев использования :)

Собственно, сырцы валяются выше по ссылке: https://git.ncrmnt.org/firmwares/SkeletonKey

Шьется в любую авр с v-usb. На кнопки можно повесить на выбор: yubikey token, реплей длинного пароля, генератор прикольных хостнеймов по тупому алгоритму.

Ты же понимаешь, что для человека, который никогда не программировал микроконтроллеры, эти исходники без хотя-бы минимального README абсолютно бесполезны.

yubikey token

Меня больше интересует именно это, т.к. его, вроде, можно с Linux PAM интегрировать.

Например YubiKey Security Key или Thetis FIDO U2F Security Key with Bluetooth стоят около 100 евро.

Thetis FIDO U2F Security Key $19.99

Thetis BLE U2F Security Key $29.99

Вот с этим большая проблема была, от чего я и не допилил до логического завершения тот проект, а так и оставил в минимальном виде.

1. В том виде, в котором я тогда ковырял, надо было поднимать сервер авторизации с пыхпыхом. Сейчас, как я понимаю, тоже. Если у тебя официальный ключ, то, как я понимаю, ты можешь использовать облако yubi. Причем то, как опенсурс тулы были написаны уверенности не вселяли совершенно, и несколько раз отваливались на моем тестовом сетапе.

2. Вытекает из пункта 1. Где держать сервера авторизации? Малейший отвал интернета или сети, и мы уже не сможем залогиниться в PAM. А это неприятно даже на моем минимальном сетами (дача и дом с бриджем по впн)

3. Интеграция с LDAP. Вот это ад и израиль. Я больше занимался любовью с LDAP’ом, чем разводил плату, паял и прогал мк. Уже не помню деталей, но для того, чтобы она взлетела надо было на тот момент либо очень здорово уродовать схему, от чего iRedMail’у плохело, либо патчить OpenLDAP. Я хотел, добавив yubi в LDAP сразу фактически сделать авторизацию через OTP для всех приложений, работающих с LDAP. Не выгорело. Один из примеров - почтовый сервер и nextcloud/rainloop. nextcloud реюзает введенный пароль для логина уже по IMAP, но если пароль протухает при его использовании. В итоге у каждого приложения были свои загоны. Ну и плюс постоянные отвали этой системы-ниппель при обновлении.

Возможно сейчас это дело немного улучшили и отполировали, но тогда это был орочий ад. В общем я тогда и решил отложить это дело до лучших времен. Возможно если появится время, освежу в памяти и поковыряю еще. Ну или подкину тебе ключик, а ты расскажешь о приключениях. Аппаратура тут самая самая простая штука, как оказалось ;)

надо было поднимать сервер авторизации

Погоди, так ключ не автономный значит?

Может тогда лучше посмотреть в сторону чего-то другого, что можеть работать с PAM без проблем?

В этом то и прикол. приложение, получающее одноразовый пароль должно отправить на сервер авторизации запрос по REST, там в mysql хранятся таймстемпы протухших ключей и инфа для расшифровки. Фактически эти два костыля надо разворачивать.

https://github.com/Yubico/yubikey-val

https://github.com/Yubico/yubikey-ksm

Может тогда лучше посмотреть в сторону чего-то другого, что можеть работать с PAM без проблем?

PAM для меня было некритично, хотелось добавить двухфакторку к веб-сервисам типа nextcloud, gitlab и прочим. Но по ходу везде нужна поддержка OTP самим приложением. Печаль, в общем.

А если просто что-то типа DIY смарткарты сделать?

У меня валялось пара рутокенов старых, вроде поддерживаются через opensc, но определяется через opensc только один, и 3/4 команд не работают. Периодически когда обновляю систему тыкаю, не заработали ли, но пока ощущение, что с opensc все печально.

Отдельная проблема это дрова. Плюс йубика - если надо залогиниться в вебморду с потенциально протрояненного компа чужого, и не спалить пароль. А с opensc надо накатывать дрова для pkcs11, а в Винде это вообще пляски с бубном в виде криптопро.

В общем, все печально.

напишешь реализацию FIDO2 CTAP в 8 килобайтах?

в yubikey u2f (и otp, в старших моделях).

А ключ-то ты где возьмешь?

Тогда что-то не сходится. Возможно U2F и OTP добавили сильно позже, уже после того, как я их ковырял. Для OTP надо точно переделывать схематику, т.к. нужна батарейка и RTC.

напишешь реализацию FIDO2 CTAP в 8 килобайтах?

микроконтроллеры и побогаче бывают. А еще к ним память приделывается. Ничего сложного не вижу, при желании

Особые извращенцы могут конечно в усб стик и Линукс зашифрованный и с секурьбутом запихнуть, хехе. Было бы желание.

Все что вы тут перечислили может быть прочитано. Я не просто так про смарт карты написал. Ваш ширпотреб прочтут и ключи сольют. А совсем без защиты есть например миландр, с фьюзами у них контроллеров пока не видел. Да и китайчатина без защиты попадается. То что вы считаете защитой основано на вашей вере в точность спецификаций.

Давай я возьму с полки ближайшую самую голимую китайщину, например nuvoton 8051, зашью туда /dev/urandom с защитой от ридбэка и предложу тебе считать. Например, можем такой спор провести на хорошие кофейные зерна. Результаты реверса в опенсорс.

Особые извращенцы могут конечно в усб стик и Линукс зашифрованный и с секурьбутом запихнуть, хехе. Было бы желание.

почему сразу извращенцы? мож люди так развлекаются? у нас ведь как: если твое хобби — марки или монеты собирать — нормально, если в филармонию ходить скрипку слушать — вообще замечательно, а если человек по горам лазает или там перса качает — ну дурак дураком же...

я к чему — многие находят удовольствие в том, чтоб запихнуть самописного супермарио в 8кб атмеги, на мой взгляд — хобби не хуже других

Это был сарказм ;)

Почему нет?

Ну, вот это всё уже есть в юбике за какие-то небольшие деньги.

Потому что тогда можно мысленно разделить ключ на десять частей и получить 10 факторов не вставая с места.

Так иногда и делают на практике - см Shamir Secret Sharing. И это валидно, если части ключа разданы разным людям.

Логично, только именно что требуется раздать его разным людям, каждый из которых получает свою однофакторную авторизацию, а двухфакторная авторизация в современном контексте вообще не предполагает второго человека. Наоборот, она добавляет альтернативное подтверждение для одного человека.

двухфакторная авторизация в современном контексте вообще не предполагает второго человека

Аутентификация. То, что ты путаешь два эти понятия говорит о том, что ты вообще в теме не разбираешься.

В случае юбика (и любой другой смарткарты в любом форм факторе) есть два фактора аутентификации - фактор владения (без юбика нельзя залогиниться, ключ считается неизвлекаемым) и фактор знания - пароль от юбика, чтобы он начал работать.

В Шамире ни один из людей не получает собственную аутентификацию. Он вообще не получает никакой аутентификации, часть ключа сама по себе бесполезна, она не позволяет доказать, кто её владелец.

С приватными ключами в файлах ситуация принципиально такая же, как и с юбиком - ни ключ, ни файл сами по себе не обеспечивают аутентификацию. Только их совокупность обеспечивает. То, что зашифрованный файл можно скопировать, принципиально не влияет на схему. Это создаёт другие угрозы, но число факторов не уменьшает.

ну стало быть делим в своем воображении файл побайтово и получаем 2048-4096 факторов.

То, что все эти тысячи однобайтовых ключей можно скопировать, принципиально не влияет на схему. Это создаёт другие угрозы, но число факторов не уменьшает.

ну стало быть делим в своем воображении файл побайтово и получаем 2048-4096 факторов.

дурачок, не знаешь, чем бит от байта отличается?

разница между юбиком и твоим графоманством в том, что в юбике ключ делят не в воображении.

Насколько я понимаю, юбикей в том числе реализует OTP, так что и спорить не о чем, это второй фактор. А ключ он, наоборот, не делит и вообще не трогает.