Люто плюсую... Для нормальных интерфейсов взаимодействия с пользователем нужно использовать научную эргономику, а не "вот мне так захотелось, нравится и к тому же это не как у всех"...
Для резервирования "жизненно необходимого" обычно достаточно 3 кВА на 6 часов (если у вас не электроплита на кухне, а кушать хочется)... Поскольку полную мощность потреблять вы будете 1 час, а остальное время получится при 1,5-2 кВА.
Сам биометрический сканер дает только "приблизительные/ориентировочные" данные. Именно по этой причине при их первоначальном получении (для сохранения их хеша) данные нескольких попыток сканирования/получения усредняют...
Биометрия <> абсолютная идентичность каждый раз при получении
Из этого следует -
поиск по хешу в случае биометрии не индексируется и выполняется "приблизительно" (что дико снижает его поиск в милионных БД)
Борьба за FAR/FRR для различных биометрических методов
Взламывать/подделывать иногда проще не "источник биометрии" а протокол обмена между "считывателем" биометрии и системой ее обработки/хранения (особенно с учетом того что зачастую со считывателя уже передается готовый хеш).
Ваше желание "подогнать задачу" под ваш "готовый ответ" вполне понятно, но... 1. На старте лучше определиться с первоначальной реализуемой задачей и целевой аудитории, и с дальнейшим развитием. По логике - от этого будет отправная точка для реализации задачи целевой аудитории. 2. Попытка целевой аудитории объяснить - "Мы лучше вас знаем что вам нужно!", удается только монстрам бизнеса (типа Apple), а стартапам больше подходит лозунг - "А мы для вас за разумные деньги умеем вот так и вот так, и вообще за небольшие деньги сверху так как вам угодно!" Опять же. Варианта "войти на рынок" всего два - соответствие "стандартным" монтажным размерам врезных/накладных замков или "внутренняя накладка" на уже установленные замки. Первый вариант для "экспериментаторов" готовых поверить в ваши заявления о механических свойствах ваших замков, второй для кучи потенциальных пользователей с уже "выбранными" и установленными ими в дверях моделями замков/ключей (готовыми "расширить" возможности их "ключей" для замков за разумные деньги)... Теперь про "модульность" конструктивного исполнения. Для "безболезненного роста" функциональности (учитывая текущие предлагаемые решения от других аналогичных поставщиков) лучше сразу делить на "исполнительный механизм" и "модули разных типов ключей". "Исполнительный механизм" - открытие/закрытие в виде выше описанных вариантов. "Модуль ключей" (или несколько различных модулей) - на выбор пользователей. Хотите NFС, кодовую панель, биометрию, WIFI, GSM, радиоканал, BLE, интеграцию с "умным домом" или что-то еще - покупайте соотвествующий модуль или несколько и соедините их с "исполнительным механизмом"(причем проводом для исключения возможности удаленного воздействия и по нему же и питание исполнительного механизма). Выбор способа питания замка - опять же выбор пользователя (с четким объяснением ему всех возможностей/преимуществ/недостатков) автономное, сетевое, сетевое с аварийным поддержанием и т.п. На существующем уже рынке замков/ключей не дураки сидят и большинство уже готовых решений появились "не просто так". Но вот отечественных проработанных решений и поставщиков как то "не видно". Нужно четко понимать и учитывать что требования к замкам дверей и ключей у жителей квартир многоэтажек, загородных домов/котеджей, владельцев и арендаторов различные.
1) Китайская платформа с негарантированным отсутствием аппаратных закладок 2) Bootloader взламывается легко (что не секрет), а это = отсутствие безопасной загрузки OS.
:-) У вас проблемы с внедрением? А не пробовали делать нормальную аналитику? К приведенному в статье примеру. Никто же и никогда не догадывался что бывают "солнечные зайчики" или "мокрые и грязные вагоны"... Это же просто "вершина аналитической мысли", и аджайл тут не поможет! :-)
:-) Ну вопрос же не в том чтобы один человек во всем разбирался, а в том чтобы он отвечал за принятие решения... "Коллективная ответственность (принятие решения)" = "нет ответственности"...
Да уж... Нет Java = нет необходимости "прогрева" = нет проблем с переключением кластерных нодов... :-) Поскольку проблем с "прогревом" кластеров БД и так уже достаточно... :-)
:-) Судя по информации бюрократия банка не позволяла и не позволяет делать нормальных решений, когда только один человек координирует и отвечает за все функционирующие и планируемые IT системы. В "новом" бизнес-процессе получили ту же самую "размазанную коллективную ответственность" при запуске новых систем (ну хотя бы "закрепили ответственность" за уже существующие системы). Правда кто будет отвечать за новые, тесно взаимодействующие со "старыми", где у каждой свой ответственный/владелец который никогда не хочет чтобы именно его систему "трогали", не определили....
Вероятнее всего в этом случае что system раздел у вас "виртуальный" и сжатый (а не фактический расположенный на emmc флеш). Нужно смотреть результат команд mount , cat /proc/inand , cat /proc/partitions. Определять раздел emmc "мапируемый" на ваш system. Скачивать образ раздела на комп, распаковывать, модифицировать (заменять нужный вам файл на новый), упаковывать (возможно пересчитывать контрольные суммы или переподписывать его) и только после этого записывать раздел на emmc. Хотя теоретически это можно сделать и на самом устройстве через командную строку (если есть поддержка структур "упаковки" виртуальных разделов в фактические на emmc). Все не просто... :-)
При наличии root и adb доступа через usb или wifi довольно легко через консоль... Но фактический набор команд зависит от конкретной прошивки (наличия и состояния разделов). Общий план действия (если system можно перемонтировать в rw режим) 1) adb push <нужный файл> /tmp/ 2) adb root 3) adb remount 4) adb shell su stop zygote cp /tmp/<нужный файл> <путь+имя до старого заменяемого> chown root.root <путь+имя нового файла> chmod 644 <путь+имя нового файла> sync start zygote (ну или reboot) Примерно так...
Список разделов приведен довольно устаревший... На новых версия Android уже "по другому" (recovery к примеру отдельного уже нет)... Обход проверки подписей разделов при загрузке может быть реализован "по разному", но при наличии "правильного" Qualcomm загрузчика (обычно он "выковыривается" из "полной" прошивки устройства для PC) уже можно экспериментировать с разделами флеш, есть соответствующий софт позволяющий получить информацию с emmc даже без наличия root доступа через bootloader режим устройства.
Выбирать можно если тебе предоставляют такой выбор... :-) 1 и 2 (в случае утери/компроментации) можно сменить (удостоверив личность по "бумажке"/паспорту).... С 3-им - все гораздо хуже.... Любой софтверный (аппаратный) HSM (генератор паролей, хранилище ключей) всегда менее надежен аппаратного с неизвлекаемыми ключами/сертификатами... Причем цена хардверного ~= цене смарт/SIM карте.... Добавь к чиповой смарт карте ридер с экраном и кнопками (=цена кнопочного телефона) - и вот тебе надежное аппаратное устройство... Но.... Это видимо "не кошерно" для наших "специалистов" по безопасности...
"можно уже токены c поддержкой гостовской ЭП брать" - открыл ты браузер "на чужом" компьютере без возможности устанавливать ПО, и... токеном то как пользоваться? :-) Идея со смарткартой (ex УЭК) - как единый защищенный внешний HSM с криптоключами и сертификатами - была самая здравая.... Покупаешь ридер с экраном - вот тебе и безопасность и приватность и личная защита персональных данных которые в нем храняться.
Ну со смартфонами (или телефонами) это норм, когда включаешь - а он говорит "ой не могу... заряди..." :-) А какие есть предложения аппаратных TOTP (без внешних интерфейсов, только с экраном) с поддержкой работы с госуслугами? Может кто-то озвучить? Ну и цена чтоб не превышала стоимости хотя бы среднего по цене смартфона....
Люто плюсую... Для нормальных интерфейсов взаимодействия с пользователем нужно использовать научную эргономику, а не "вот мне так захотелось, нравится и к тому же это не как у всех"...
Для резервирования "жизненно необходимого" обычно достаточно 3 кВА на 6 часов (если у вас не электроплита на кухне, а кушать хочется)... Поскольку полную мощность потреблять вы будете 1 час, а остальное время получится при 1,5-2 кВА.
Сам биометрический сканер дает только "приблизительные/ориентировочные" данные. Именно по этой причине при их первоначальном получении (для сохранения их хеша) данные нескольких попыток сканирования/получения усредняют...
Биометрия = хеш
Биометрия <> абсолютная идентичность каждый раз при получении
Из этого следует -
поиск по хешу в случае биометрии не индексируется и выполняется "приблизительно" (что дико снижает его поиск в милионных БД)
Борьба за FAR/FRR для различных биометрических методов
Взламывать/подделывать иногда проще не "источник биометрии" а протокол обмена между "считывателем" биометрии и системой ее обработки/хранения (особенно с учетом того что зачастую со считывателя уже передается готовый хеш).
Судя по темпам "импортозамещения" пропускная способность оборудования РКН под большим вопросом...
Ваше желание "подогнать задачу" под ваш "готовый ответ" вполне понятно, но...
1. На старте лучше определиться с первоначальной реализуемой задачей и целевой аудитории, и с дальнейшим развитием. По логике - от этого будет отправная точка для реализации задачи целевой аудитории.
2. Попытка целевой аудитории объяснить - "Мы лучше вас знаем что вам нужно!", удается только монстрам бизнеса (типа Apple), а стартапам больше подходит лозунг - "А мы для вас за разумные деньги умеем вот так и вот так, и вообще за небольшие деньги сверху так как вам угодно!"
Опять же. Варианта "войти на рынок" всего два - соответствие "стандартным" монтажным размерам врезных/накладных замков или "внутренняя накладка" на уже установленные замки. Первый вариант для "экспериментаторов" готовых поверить в ваши заявления о механических свойствах ваших замков, второй для кучи потенциальных пользователей с уже "выбранными" и установленными ими в дверях моделями замков/ключей (готовыми "расширить" возможности их "ключей" для замков за разумные деньги)...
Теперь про "модульность" конструктивного исполнения. Для "безболезненного роста" функциональности (учитывая текущие предлагаемые решения от других аналогичных поставщиков) лучше сразу делить на "исполнительный механизм" и "модули разных типов ключей". "Исполнительный механизм" - открытие/закрытие в виде выше описанных вариантов. "Модуль ключей" (или несколько различных модулей) - на выбор пользователей. Хотите NFС, кодовую панель, биометрию, WIFI, GSM, радиоканал, BLE, интеграцию с "умным домом" или что-то еще - покупайте соотвествующий модуль или несколько и соедините их с "исполнительным механизмом"(причем проводом для исключения возможности удаленного воздействия и по нему же и питание исполнительного механизма).
Выбор способа питания замка - опять же выбор пользователя (с четким объяснением ему всех возможностей/преимуществ/недостатков) автономное, сетевое, сетевое с аварийным поддержанием и т.п.
На существующем уже рынке замков/ключей не дураки сидят и большинство уже готовых решений появились "не просто так". Но вот отечественных проработанных решений и поставщиков как то "не видно". Нужно четко понимать и учитывать что требования к замкам дверей и ключей у жителей квартир многоэтажек, загородных домов/котеджей, владельцев и арендаторов различные.
1) Китайская платформа с негарантированным отсутствием аппаратных закладок
2) Bootloader взламывается легко (что не секрет), а это = отсутствие безопасной загрузки OS.
И про какую "защищенность" OS можно говорить на Mediatek платформе? :-)
:-) У вас проблемы с внедрением? А не пробовали делать нормальную аналитику?
К приведенному в статье примеру. Никто же и никогда не догадывался что бывают "солнечные зайчики" или "мокрые и грязные вагоны"... Это же просто "вершина аналитической мысли", и аджайл тут не поможет! :-)
Ну как бы вот... :-) https://www.waterfox.net/en-US/
:-) Ну вопрос же не в том чтобы один человек во всем разбирался, а в том чтобы он отвечал за принятие решения... "Коллективная ответственность (принятие решения)" = "нет ответственности"...
Да уж... Нет Java = нет необходимости "прогрева" = нет проблем с переключением кластерных нодов... :-)
Поскольку проблем с "прогревом" кластеров БД и так уже достаточно... :-)
:-) Судя по информации бюрократия банка не позволяла и не позволяет делать нормальных решений, когда только один человек координирует и отвечает за все функционирующие и планируемые IT системы. В "новом" бизнес-процессе получили ту же самую "размазанную коллективную ответственность" при запуске новых систем (ну хотя бы "закрепили ответственность" за уже существующие системы). Правда кто будет отвечать за новые, тесно взаимодействующие со "старыми", где у каждой свой ответственный/владелец который никогда не хочет чтобы именно его систему "трогали", не определили....
Вероятнее всего в этом случае что system раздел у вас "виртуальный" и сжатый (а не фактический расположенный на emmc флеш). Нужно смотреть результат команд mount , cat /proc/inand , cat /proc/partitions. Определять раздел emmc "мапируемый" на ваш system. Скачивать образ раздела на комп, распаковывать, модифицировать (заменять нужный вам файл на новый), упаковывать (возможно пересчитывать контрольные суммы или переподписывать его) и только после этого записывать раздел на emmc. Хотя теоретически это можно сделать и на самом устройстве через командную строку (если есть поддержка структур "упаковки" виртуальных разделов в фактические на emmc). Все не просто... :-)
При наличии root и adb доступа через usb или wifi довольно легко через консоль...
Но фактический набор команд зависит от конкретной прошивки (наличия и состояния разделов).
Общий план действия (если system можно перемонтировать в rw режим)
1) adb push <нужный файл> /tmp/
2) adb root
3) adb remount
4) adb shell
su
stop zygote
cp /tmp/<нужный файл> <путь+имя до старого заменяемого>
chown root.root <путь+имя нового файла>
chmod 644 <путь+имя нового файла>
sync
start zygote (ну или reboot)
Примерно так...
Список разделов приведен довольно устаревший... На новых версия Android уже "по другому" (recovery к примеру отдельного уже нет)... Обход проверки подписей разделов при загрузке может быть реализован "по разному", но при наличии "правильного" Qualcomm загрузчика (обычно он "выковыривается" из "полной" прошивки устройства для PC) уже можно экспериментировать с разделами флеш, есть соответствующий софт позволяющий получить информацию с emmc даже без наличия root доступа через bootloader режим устройства.
Если владельцу сервиса клиенты не нужны т.е. делает он свой сервис без "оглядки на желания потенциальных клиентов" - это конечно его выбор... :-)
Выбирать можно если тебе предоставляют такой выбор... :-)
1 и 2 (в случае утери/компроментации) можно сменить (удостоверив личность по "бумажке"/паспорту)....
С 3-им - все гораздо хуже....
Любой софтверный (аппаратный) HSM (генератор паролей, хранилище ключей) всегда менее надежен аппаратного с неизвлекаемыми ключами/сертификатами... Причем цена хардверного ~= цене смарт/SIM карте.... Добавь к чиповой смарт карте ридер с экраном и кнопками (=цена кнопочного телефона) - и вот тебе надежное аппаратное устройство... Но.... Это видимо "не кошерно" для наших "специалистов" по безопасности...
"можно уже токены c поддержкой гостовской ЭП брать" - открыл ты браузер "на чужом" компьютере без возможности устанавливать ПО, и... токеном то как пользоваться? :-)
Идея со смарткартой (ex УЭК) - как единый защищенный внешний HSM с криптоключами и сертификатами - была самая здравая.... Покупаешь ридер с экраном - вот тебе и безопасность и приватность и личная защита персональных данных которые в нем храняться.
Ну со смартфонами (или телефонами) это норм, когда включаешь - а он говорит "ой не могу... заряди..." :-)
А какие есть предложения аппаратных TOTP (без внешних интерфейсов, только с экраном) с поддержкой работы с госуслугами? Может кто-то озвучить? Ну и цена чтоб не превышала стоимости хотя бы среднего по цене смартфона....