Авторы (T. Nagase et al) в своих статьях о криптостойкости предложенной ими схемы «шифрования» ничего не сообщают.
Предложенный авторами метод key schedule слаб, т.к. N раундов, которые сводятся к одному раунду с другим ключом — это просто абзац, о чем выше коллеги уже намекнули. Тем более, если можно тривиально найти ключ по входным и выходным данным в алгоритме с одним раундом. В используемых на практике алгоритмах шифрования таких изъянов нет.
В принципе, еще можно попробовать включить автообрезку полей, работает она на M92SM, прямо скажем, не супер, но выручает. Вероятно, на M92M будет лучше, т.к. там можно пальцами вручную установить точную границу обрезки.
В зависимости от грамотности сборки PDF. Для особо запущенных случаев есть режим «Glyph Embolden», т.е. повышение жирности шрифта. Если его не включать, то некоторые двухколоночные статьи вообще читать невозможно. А если включать — вполне терпимо.
Вот фото на утюг, в условиях, максимально приближенных к боевым (20 Вт, 12В настольная галогенная лампа)
Цену задирают безнаказанно, потому что аналогов с таким экраном раз, два — и обчёлся, да и те в той же ценовой категории.
Корпус у Onyx не металлический, конечно, но пластик довольно неплох, за два года эксплуатации вокруг кнопок у меня царапин не появилось, например.
Странно, по моему опыту с аналогичного устройства от Onyx с таким же экраном (Onyx M92SM, тот же аппарат, но без wifi и сенсора) вполне терпимо читать на солнце, даже если тень «низкого качества» — зонтик из разреженной ткания a la мешковина.
Т.к. экран работает в отраженном свете, воспринимаемая глазом контрастность явно положительно зависит от уровня освещенности. Любой TFT экран без подсветки будет смотреться еще хуже по сравнению с e-ink.
Пример #1: Приложение шифрует номера кредиток в базе данных, используя дефолтное кодирование. Это означает, что при получении данных они могут быть спокойно снова раскодированы. Информация должна быть зашифрована собственноручными методами с помощью одного публичного ключа, и так, чтобы только специальные бэкендовые приложения смогли расшифровать её, используя свой приватный ключ.
Честно говоря, вот это вот недоразумение лучше бы заменить на «Пример #1. Даже и не думайте хранить или обрабатывать ценные данные в своей БД, а тем более — номера карт.».
Сразу вопросы:
1) Что за «дефолтное кодирование»? При таком подходе к криптографии никакие номера карт в своей БД вообще лучше не хранить, а просто использовать внешние платежные шлюзы (т.е. аутсорсинг услуг карточного эквайринга).
2) «зашифрована собственноручными методами» — аудиторы PCI DSS моментально покрошат Вас в винегрет. Принцип Керкгоффса сформулирован в девятнадцатом веке.
3) сама идея с выделенным сервером высказана в правильном направлении, но вот попытка для для этого самостоятельно имплементировать криптографию с открытым ключом «собственноручными методами» заведомо обречена на провал.
Насколько я понимаю, для ускорения и упрощения разработки автор принял решение взять готовую плату для BT. Это разумно, т.к. блютус — это все-таки СВЧ, нужен опыт.
А так конечно можно было развести радиоинтерфейс на обратной стороне платы и сэкономить пару-тройку миллиметров, плюс вибромотор можно было на самом корпусе закрепить, а в плате сделать вырез, аккумулятор, вероятно тоже можно было найти потоньше.
Итого миллиметров 5 бы сэкономили, ценой роста трудоемкости.
Спасибо, это решение, а то мне вот когда надо было — не от большого ума взял да сгенерил из R сотню файлов и потом руками в консоли imagemagick'ом собирал :) Тут хоть и тот же путь, но хотя бы более автоматизированный.
Статья ни о чем:
1) Большая часть текста вообще не несет никакой смысловой нагрузки для ИТ-специалиста.
2) «Продвинутые» методы и их рейтинг среди описанных просто смешны — тривиально обнаруживаются специализированными forensic средствами, включая общедоступные; потоки NTFS с самого начала умеют сканировать даже антивирусы, и т.д.
3) Про шифрование и стеганографию не дано полезной информации, одни заблуждения школьного уровня.
4) Раздел «Кто может найти скрытую информацию» наполнен беспочвеными априорными суждениями на уровне «сарафанного радио» и никак не тянет на модель нарушителя.
Она называется CUP — China UnionPay, и она уже набрала все, что можно :)
В CUP выпущено едва ли не 50% пластиковых карт всего мира — №1 по числу карт, и №2 по оборотам транзакций (после Visa).
Респект за рабочий прототип, конечно, но есть нюансы:
1) В себестоимость явно не включены трудозатраты. Положим, если Вы вдвоем за три дня все изготовили, собрали и протестировали, то это уже 6 Ч.Д. = четверть человеко-месяца, т.е. четверть зарплаты. Я понимаю, что удовлетворение от технического творчества не измеряется в деньгах, но тогда и подавать статью надо под другим соусом.
2) Вы, похоже, использовали низкотемпературный термоклей (EVA, этилвинилацетат). Он при 80 градусах уже начнет размягчаться. А у Вас я вижу его как минимум на выводах самого большого дросселя на выходе БП.
Даже китайцы в электронику заливают высокотемпературные клеи и компаунды, которые при ремонте и демонтаже плавятся только под паяльным феном на 200 градусах.
Неправда, третий домен — это Interoperability Domain, это сама платежная система и её сервисы, без которых эмитент и эквайрер никогда не договорились бы.
В момент прохождения транзакции комиссия рассчитывается по правилам платежной системы (МПС). Эмитент блокирует сумму+комиссию на карточном счету. Потом от эквайрера приходит подтверждение операции, и блокировка на карточном счету для держателя карты превращается в реальное списание. Дальше оба банка и МПС рассчитываются между собой. В случае конвертации валют и колебаний курсов в течение этого процесса (а он идет не в реальном времени) с карточного счета держателя может быть списана бОльшая сумма, чем была заблокирована.
Т.е. миллион карт, по которым сменили PIN = миллион новых PVK в БД эмитента? И stand-in сервисы проверки PIN от платежных систем у Вас, получается, совершенно не совместимы с услугой PIN Change, или эмитенту придется выгрузить в онлайне в МПС миллион ключей PVK, что невероятно (там даже интерфейсов таких нет).
Нам все равно придется идти к эмитенту, даже после оффлайновой проверки, чтобы удостовериться окончательно и вызвать полицию, поэтому придется делать хитрый апплет с проверкой двух пинов…
Короче, проще, конечно, реализовывать исходный бред на отдельном чиповом апплете, как для биометрии делают, чем пытаться вклиниться в существующую схему :)
Чип в онлайне в части проверки PIN не сильно отличается от магнитки. PIN-то все равно проверяет эмитент по тем же транзакционным данным.
В оффлайне смысла для тревожного PIN нет никакого. Плюс всегда можно разработать свой чиповый апплет, который и на онлайне будет угадывать, какой PIN введен — обычный или тревожный, и т.д.
В реальной жизни, конечно, никто это делать не будет :)
Кстати, эмитенту-то на PCI DSS вообще-то можно аргументированно положить с приборомcompensating controls, т.к. он предназначался для эквайреров и ТСП.
Вы не совсем правы :) То, что PIN в открытом виде нигде не фигурирует, нисколько не мешает с ним работать — Вы же знаете набор команд HSM.
Техническая возможность на стороне эмитента есть, эмитенту достаточно просто хранить в БД удвоенный набор данных — для прямого и обратного PIN. Да, никто так не работает, но этот бред вполне работоспособен. Можно и на трек записать два PVV и вполне PCI DSS-но проверять PIN по обоим, не храня в БД вообще ничего, кроме PAN, Expiry Date и сервис-кода (что эмитент всегда имеет право хранить).
Вот реализация PIN Change с гипотетическим тревожным PIN превратится в ад, это да.
Не говоря уж и про то, что когда эмитент ушел в stand-in, платежная система никаких полицейских вызвать не сможет :)
Оно всполне себе осуществимо — достаточно просто на стороне эмитента хранить два PVV / два шифрованных PIN-блока /…
Или, чтобы это было PCI DSS совместимо, записать на карту два PVV и проверять входящий PIN-блок на совпадение с одним из них.
Предложенный авторами метод key schedule слаб, т.к. N раундов, которые сводятся к одному раунду с другим ключом — это просто абзац, о чем выше коллеги уже намекнули. Тем более, если можно тривиально найти ключ по входным и выходным данным в алгоритме с одним раундом. В используемых на практике алгоритмах шифрования таких изъянов нет.
Корпус у Onyx не металлический, конечно, но пластик довольно неплох, за два года эксплуатации вокруг кнопок у меня царапин не появилось, например.
Т.к. экран работает в отраженном свете, воспринимаемая глазом контрастность явно положительно зависит от уровня освещенности. Любой TFT экран без подсветки будет смотреться еще хуже по сравнению с e-ink.
Честно говоря, вот это вот недоразумение лучше бы заменить на «Пример #1. Даже и не думайте хранить или обрабатывать ценные данные в своей БД, а тем более — номера карт.».
Сразу вопросы:
1) Что за «дефолтное кодирование»? При таком подходе к криптографии никакие номера карт в своей БД вообще лучше не хранить, а просто использовать внешние платежные шлюзы (т.е. аутсорсинг услуг карточного эквайринга).
2) «зашифрована собственноручными методами» — аудиторы PCI DSS моментально покрошат Вас в винегрет. Принцип Керкгоффса сформулирован в девятнадцатом веке.
3) сама идея с выделенным сервером высказана в правильном направлении, но вот попытка для для этого самостоятельно имплементировать криптографию с открытым ключом «собственноручными методами» заведомо обречена на провал.
А так конечно можно было развести радиоинтерфейс на обратной стороне платы и сэкономить пару-тройку миллиметров, плюс вибромотор можно было на самом корпусе закрепить, а в плате сделать вырез, аккумулятор, вероятно тоже можно было найти потоньше.
Итого миллиметров 5 бы сэкономили, ценой роста трудоемкости.
1) Большая часть текста вообще не несет никакой смысловой нагрузки для ИТ-специалиста.
2) «Продвинутые» методы и их рейтинг среди описанных просто смешны — тривиально обнаруживаются специализированными forensic средствами, включая общедоступные; потоки NTFS с самого начала умеют сканировать даже антивирусы, и т.д.
3) Про шифрование и стеганографию не дано полезной информации, одни заблуждения школьного уровня.
4) Раздел «Кто может найти скрытую информацию» наполнен беспочвеными априорными суждениями на уровне «сарафанного радио» и никак не тянет на модель нарушителя.
В CUP выпущено едва ли не 50% пластиковых карт всего мира — №1 по числу карт, и №2 по оборотам транзакций (после Visa).
1) В себестоимость явно не включены трудозатраты. Положим, если Вы вдвоем за три дня все изготовили, собрали и протестировали, то это уже 6 Ч.Д. = четверть человеко-месяца, т.е. четверть зарплаты. Я понимаю, что удовлетворение от технического творчества не измеряется в деньгах, но тогда и подавать статью надо под другим соусом.
2) Вы, похоже, использовали низкотемпературный термоклей (EVA, этилвинилацетат). Он при 80 градусах уже начнет размягчаться. А у Вас я вижу его как минимум на выводах самого большого дросселя на выходе БП.
Даже китайцы в электронику заливают высокотемпературные клеи и компаунды, которые при ремонте и демонтаже плавятся только под паяльным феном на 200 градусах.
Короче, проще, конечно, реализовывать исходный бред на отдельном чиповом апплете, как для биометрии делают, чем пытаться вклиниться в существующую схему :)
В оффлайне смысла для тревожного PIN нет никакого. Плюс всегда можно разработать свой чиповый апплет, который и на онлайне будет угадывать, какой PIN введен — обычный или тревожный, и т.д.
В реальной жизни, конечно, никто это делать не будет :)
Кстати, эмитенту-то на PCI DSS вообще-то можно аргументированно положить с
приборомcompensating controls, т.к. он предназначался для эквайреров и ТСП.Техническая возможность на стороне эмитента есть, эмитенту достаточно просто хранить в БД удвоенный набор данных — для прямого и обратного PIN. Да, никто так не работает, но этот бред вполне работоспособен. Можно и на трек записать два PVV и вполне PCI DSS-но проверять PIN по обоим, не храня в БД вообще ничего, кроме PAN, Expiry Date и сервис-кода (что эмитент всегда имеет право хранить).
Вот реализация PIN Change с гипотетическим тревожным PIN превратится в ад, это да.
Не говоря уж и про то, что когда эмитент ушел в stand-in, платежная система никаких полицейских вызвать не сможет :)
Или, чтобы это было PCI DSS совместимо, записать на карту два PVV и проверять входящий PIN-блок на совпадение с одним из них.