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


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


Эти задачи традиционно решаются с использованием средств строгой двухфакторной аутентификации и электронной подписи, выполненных в виде USB-токенов или смарт-карт (далее – токены).


Токены, имеющиеся на нашем рынке, условно можно разделить на 2 типа:


  • хранят закрытый ключ в контейнере, доступ к которому для прикладного ПО предоставляется при предъявлении PIN-кода. Подпись при этом формируется программным СКЗИ в оперативной памяти ПК. Закрытый ключ при формировании подписи покидает токен, т.е. является извлекаемым;
  • самостоятельно генерируют ключевую пару (закрытый/открытый ключ). Подпись формируется «на борту» токена, в токен для этого передается хеш документа. Закрытый ключ никогда не покидает токен, т.е. является неизвлекаемым.

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


  1. Вредоносное ПО перехватывает PIN-код для токена при его вводе на клавиатуре ПК, затем с помощью этого PIN-кода расшифровывает содержимое контейнера на токене, получая таким образом доступ к самому закрытому ключу.
  2. Вредоносное ПО перехватывает закрытый ключ в оперативной памяти ПК в ходе выполнения операции, требующей его использования (например, при формировании ЭП).

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


При использовании токена второго типа, с неизвлекаемым ключом электронной подписи, такой токен надёжно защища¬ет ключ от кражи. Однако киберпреступники с помощью вредоносного ПО, сделанного с учетом специфики работы атакуемой системы, научились подписывать поддельные документы без кражи ключей.


  1. Атаки с подменой подписываемого документа. Пользователь видит на экране ПК одно платёжное поручение, а в момент его подписания вредонос¬ное ПО незаметно подменяет в нём реквизиты получателя и сумму. В токен для вычисления ЭП отправляется хеш подмененного документа. В результате деньги со счёта клиента банка «уходят» на счёт киберпреступника. Более того, вредоносное ПО после этого способно подменять отображаемые клиенту банка остатки на счетах. В результате пользователь может долго не подозревать о совершённой краже. Такие атаку могут быть реализованы различными способами.

    • Перехват трафика по протоколу USB-CCID.
    • Внедрение в код банковского приложения или браузера. Шифрованный канал, который может быть установлен между банковским приложением и токеном, в этом случае не помогает.

  2. Атаки, использующие состояние «залогиненности» токена. Получив удалённое управление, или, внедрив вредоносное ПО на компьютер клиента банка, киберпреступник может подписывать любые поддельные документы на его ключах в период, когда токен подключен к ПК и пользователь перед этим ввёл PIN-код. Перехватив заранее PIN-код с помощью вредоносного ПО, киберпреступник может сам «залогиниться» на токене и подписать на нём поддельный документ. Виртуальные клавиатуры не дают гарантию защиты от перехвата PIN-кода.

Можно снизить риски подобных атак путём чёткого следования политикам безопасности:


  • пользоваться легальным сертифицированным ПО;
  • своевременно устанавливать обновления;
  • установить и правильно настроить межсетевой экран;
  • использовать антивирус со свежей обновлённой базой;
  • установить и настроить модуль доверенной загрузки и контроля целостности среды.

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


Необходимость дополнительной защиты от мошенников известна и банкам, и регулятору. Данная проблема является достаточно актуальной. В частности, по информации «КоммерсантЪ» от 14 июля 2016 г. Минфин и ЦБ подготовили новые поправки по защите клиентов банков от несанкционированных операций. Поправки предлагают наделить банки правом приостанавливать транзакции, если есть подозрение, что операция совершается без согласия клиента, несмотря на правильно введённый пин-код и использование реальной электронной подписи. Т.е. масштаб бедствия таков, что законодатель явно допускает фрод и готовит рекомендации по противодействию ему.


Что реально используется сегодня для защиты от кражи денежных средств


Для защиты от кражи денежных средств в системах ДБО банки внедряют дополнительные меры.


  1. Серверные антифрод-системы, позволяющие выявлять подозрительные транзакции по тем или иным признакам.
  2. Trust Screen-устройства на клиентской стороне, позволяющие подтверждать ключевые реквизиты платёжных документов в доверенной среде таких устройств.

Серверные антифрод-системы


Серверные антифрод-системы, использующие те или иные математические модели, в том числе технологии машинного обучения, с учётом накопления данных позволяют со временем снижать вероятность возникновения ошибок первого (ложная тревога) и второго (пропуск реальной атаки) родов, что положительно сказывается на их эффективности. Плюсом таких антифрод-систем с точки зрения пользователей Интернет-банкинга является то, что такие системы, как правило, не изменяют обычный для пользователя порядок вещей. Пользователь как работал с системой, так и продолжает работать, от него не требуется выполнять дополнительные действия.


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




Идентификация, как правило, используется для представления своего идентификатора, а аутентификация – для доказательства, что субъект является тем, за кого себя выдаёт.


Голосовая идентификация не даёт 100% гарантию, что на том конце клиент банка. Существует технологии и даже готовые решения для клонирования голоса. И вполне возможно, что киберпреступники уже умеют или в ближайшем будущем научатся подделывать голос «жерты» так, чтобы успешно обманывать системы распознавания. Вместе с тем распознавание голоса является еще одним эшелоном, который позволяет снизить риск кражи денежных средств.


Trust Screen-устройства



Trust Screen-устройство, как правило, представляют из себя небольшое устройство с экраном и (опционально) кнопками. Такое устройство используются на клиентской стороне и его основная задача – дать пользователю возможность подтвердить (или отклонить) транзакцию в доверенной среде, отличной от среды компьютера, в котором создаются платёжные документы. Классический сценарий использования Tust Screen-устройства выглядит так:


  1. Пользователь на компьютере подготавливает платёжное поручение с указанием реквизитов получателя и даёт банковскому приложению команду подписать платёжный документ и отправить его на исполнение.
  2. Банковское приложение отображает платёжный документ на экране ПК и дополнительно просит подтвердить его ключевые реквизиты на Trust Screen-устройстве.
  3. Пользователь смотрит на экран Trust Screen-устройства и подтверждает операцию специальной кнопкой на устройстве (или на сенсорномэкране устройства).
  4. В случае подтверждения платёжный документ подписывается с помощью используемого средства ЭП и подпись отправляется на сервер.

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


Слабым звеном при корректной реализации остаётся пользователь. Возможность кражи денежных средств в этом случае определяется тем, насколько ответственно пользователь сверяет реквизиты на Trust Screen-устройстве. Если при интенсивной работе заставлять его ежедневно подтверждать сотни документов, пользователь может начать делать это машинально, не уделяя достаточного внимания тому, что именно выводится на экран устройства. В связи с этим сценарий интеграции таких устройств в банковские системы должен уделять особое внимание удобству их использования.


К счастью, есть хороший способ существенно снизить количество документов, которые потребуется подтверждать на Trust Screen-устройстве без ущерба для безопасности. Решение – использовать «белые списки» доверенных контрагентов. В такой список включаются те контрагенты, с которыми пользователь работает регулярно и которым доверяет. Чем больше доля таких контрагентов, тем меньше транзакций требуется дополнительно подтверждать. Если из 100 транзакций около 90 будут исходить в адрес доверенных контрагентов, то пользователю потребуется подтвердить только 10 из 100.


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


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


Антифрод-терминал




Некоторое время назад мы вывели на рынок Trust Screen-устройство Антифрод-терминал. Данный продукт разрабатывался нами совместно с компанией Vasco, был основан на хорошо зарекомендовавшем себя устройстве DIGIPASS 920, которое было продано по всему миру в количестве более миллиона штук. Именно поэтому Антифрод-терминал так похож на него внешне.


Особенность Антифрод-терминала заключается в том, что устройство:


  1. Ведёт внутренний журнал операций. В этом журнале фиксируется информация, которая была отображена на экране устройства и подтверждена пользователем путём нажатия кнопки «ОК» на клавиатуре устройства.
  2. Содержит собственный криптографический чип, в котором реализована российская криптография.
  3. Подписывает журнал операций собственной ЭП на этом чипе.

Журнал операций не хранится в устройстве постоянно. Антифрод-терминал начинает вести журнал каждый раз заново при начале т.н. SWYX-режима работы устройства. SWYX означает Sign What You eXecuted – подписываю то, что выполняется. По окончании SWYX-режима терминал подписывает журнал собственной ЭП и возвращает его вместе с подписью в прикладное ПО. Для управления SWYX-режимом есть специальные команды, которые прикладное ПО отправляет на терминал.


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





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


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


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


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


Новая версия Антифрод-терминала поддерживает любые типы средств ЭП


Первая версия Антифрод-терминала в качестве средства ЭП умела работать только со смарт-картами, которые подключались непосредственно к устройству. Однако на российском рынке за много лет накопилось достаточно большая инсталляционная база средств ЭП, выполненных в виде программных СКЗИ и/или USB-токенов. А переход на новые типы средств ЭП требует времени и дополнительных затрат как для банков, так и для конечных клиентов.


В связи с этим нами была разработана новая версия Антифрод-терминала, которая не накладывает никаких ограничений на тип используемого средства ЭП. Это может быть и программное СКЗИ, хранящее ключ в реестре или на обычной флешке, и программное СКЗИ, хранящее ключ ЭП на отчуждаемом USB-токене, и USB-токен с неизвлекаемым ключом ЭП, и смарт-карта ISO 7816.


Как нам удалось достичь этого? Архитектура Антифрод-терминала позволила полностью отделить функцию подписания документа от функции подтверждения на Антифрод-терминале. Работа со средством ЭП осуществляется как бы независимо от Антифрод-терминала. Средство ЭП ничего не знает о наличии Антифрод-терминала, а Антифрод-терминал ничего не знает о типе используемого средства ЭП, ему это и не нужно.



Если в качестве средства ЭП используется USB-токен, то он подключается в один USB-порт ПК, а Антифрод-терминал – в другой. Прикладное ПО работает с USB-токеном как со средством ЭП, а с Антифрод-терминалом как со средством доверенного подтверждения ключевых реквизитов документа.


Выполнение групповых операций


Для сокращения документов, которые нужно подтверждать на терминале, следует использовать «белые списки» доверенных контрагентов.


Важно то, что Антифрод-терминал позволяет безопасно создавать и изменять такие списки. Для этого достаточно все операции, связанные с изменением «белого списка», в том числе его создание, подтверждать на Антифрод-терминале. Это защищает от несанкционированного внесения изменений в «белый список» киберпреступниками.





При выполнении групповой операции достаточно подтвердить сводное платёжное поручение в адрес всех контрагентов, попавших в «белый список», и каждое поручение в адрес контрагентов, не попавших в «белый список».


Для всех получателей, попавших в «белый список», клиент подписывает и подтверждает на терминале одно сводное платёжное поручение, содержащее, например:


  • общую сумму платежа в адрес получателей из «белого списка»;
  • число таких получателей или их список.





Клиент подписывает и подтверждает на терминале каждое и оставшихся платёжных поручений.



Подписание произвольных документов


Антифрод-терминал позволяет отображать на своем экране любые текстовые данные длинной до 400 символом.


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




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


Особенность интеграции Антифрод-терминала в прикладное ПО


При интеграции терминала в прикладное ПО доработки выполняются на клиентской и на серверной сторонах.


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


Перед обычным подписанием документа прикладная программа дополнительно:


  • формирует текстовую строку (до 400 символов), содержащую ключевые реквизиты документа;
  • отправляет эту текстовую строку на Антифрод-терминал и получает подтверждение/отклонение пользователя.

После обычного подписания документа прикладная программа дополнительно:


  • запрашивает у Антифрод-терминала журнал операций;
  • отправляет журнал операций вместе с подписанным документом на сервер ДБО.




Сервер получает от клиента не только платёжный документ, но и подписанный журнал операций


После обычной проверки подписи документа прикладная программа дополнительно:


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




В профиле клиента сохраняется журнал операций (нужен при разборе конфликтных ситуаций)


Тем самым на сервере дополнительно формируется юридически значимая доказательная база (с УЭП), что клиент получил именно этот документ, видел его и подтвердил подписание на своём (полученном в банке на своё имя) терминале.

Для интеграции Антифрод-терминала мы подготовили 2 типа комплектов разработчика:

  1. JaCarta SDK – для интеграции в десктопные приложения.
  2. JC-WebClient SDK – для интеграции в веб-приложения с поддержкой всех популярных браузеров.

Поделиться с друзьями
-->

Комментарии (10)


  1. teifo
    22.09.2016 07:37
    +1

    Для меня до сих пор загадка, вот почему такие важные вещи как цифры в счетах никак не разделяются по группам. 12,14 цифр слиты воедино и плохо разборчивы. А ведь ошибиться ни в одной нельзя, неужели их так сложно разбивать на группы по 3-4 цифры, чтобы допускать меньше ошибок при сверке?


    1. nafonya
      22.09.2016 10:28

      Верно говорите — гораздо удобнее сверять длинные последовательности цифр, если они разделены на группы. Справедливости ради стоит отметить, что на приведённых картинках с подтверждением платёжных поручений цифры в счетах как раз разделены точкой на группы в соответствии со структурой счета.
      Устройство в целом не накладывает никаких ограничений на то, как будет представлена информация, выводимая на его экран. Оно отображает ровно ту текстовую строку, которая передаётся ему из прикладной программы. Прикладная программа конечно же должна для удобства отображать длинные последовательности цифр по группам как на экране ПК, так и на экране устройства.


      1. teifo
        23.09.2016 12:21

        Я скорее про Счет № 444556789 сложнее для проверки чем № 444-556-789. Конечно финансисты прочитывают 12 значные номера влет и сверка для них не проблема и они никогда не путаются в счетах и их номерах. А вот для остальных, обычных людей, второй вариант записи куда удобнее, на мой взгляд, и в ним сложнее допустить ошибку при сверке.


  1. RomanKharin
    22.09.2016 22:00

    Что предлагается:

    Приложение JC-WebClient, выполненное в виде локального Web-сервера, обрабатывающего локальные HTTPS-запросы.
    Ведётся работа над поддержкой JC-WebClient 3.0 в Mac OS X и Linux.


  1. Neraverin
    22.09.2016 22:00

    «Белые списки» надо обязательно создавать на Антифорд-терминале? В реальности у меня может быть сотня таких терминалов и сотня записей в «белом списке». Руками забить 10 000 записей?


    1. nafonya
      23.09.2016 19:14

      Теоретически “белые списки” можно создавать как угодно: печатать на принтере и относить в банк на бумаге, отправлять по email, сообщать голосом по телефону. Но если среда создания/подтверждения этого списка не является “доверенной”, то к такому “белому списку” не может быть доверия. Компьютер клиента, канал связи и даже принтер, как правило, не являются доверенной средой. Антифрод-терминал же позволяет обеспечить необходимую доверенную среду при создании “белого списка” и последующих операциях внесения изменений в этот список.
      Сами “белые списки” в Антифрод-терминале не хранятся. Они централизовано ведутся на серверной стороне. При создании “белого списка” или при внесении изменений в него терминал сформирует собственный журнал и подпишет его своей ЭП. Сервер проверит подпись журнала, убедившись в том, что терминал доверенный. После этого по журналу сервер убедится, что запрашиваемые клиентом изменения в “белый список” действительно подтверждены на доверенном терминале.

      Руками клиенту ничего забивать не нужно. Прикладное ПО само отобразит на терминале изменения, которые нужно подтвердить. Клиенту нужно будет только нажать клавишу “OK” на клавиатуре терминала для подтверждения.

      Возможны два основных сценария внесения изменений в «белый список»:
      1. Внесение изменений в «белый список» инициирует сам банк. Например, если банк увидел, что клиент уже переводил какому-то контрагенту денежные средства, то при повторном переводе предложит клиенту добавить контрагента в «белый список», чтобы в дальнейшем не подтверждать операции в адрес этого контрагента на терминале. Клиенту достаточно будет только подтвердить согласие на «Антифрод-терминале».
      2. Внесение изменений в «белый список» инициирует клиент. В этом случае клиент сам выбирает контрагентов, которых он хочет добавить в «белый список» и подтверждает операцию на терминале.

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


  1. altervision
    22.09.2016 22:02

    Сверять на антифрод-терминале несколько строк, в особенности номера счетов в банке — достаточно трудоёмкая задача, не так и трудно допустить при этом ошибку.
    А возможно ли использовать какой-либо укороченный вариант? Например, предложить пользователю не все данные целиком, а некий их хеш, своеобразный пин-код, сверить который будет гораздо проще. Или же такой хеш / пин-код слишком просто подделывается?


    1. mayorovp
      23.09.2016 06:42

      А как пользователь будет его вычислять?


  1. plus79501445397
    22.09.2016 22:03

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


    Я так понял, ключ на терминале генерируется производителем или банком, но не подписантом клиента (т.е. не является личной тайной подписанта клиента). Отдельный приватный ключ ЭП подписанта клиента терминал ни как не защищает. На основе чего банк сможет доказать свою непричастность в случае платежа, от которого подписант клиента в последствии вдруг станет отказываться?

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


    1. nafonya
      23.09.2016 20:33

      Я так понял, ключ на терминале генерируется производителем или банком, но не подписантом клиента (т.е. не является личной тайной подписанта клиента).


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

      Отдельный приватный ключ ЭП подписанта клиента терминал ни как не защищает. На основе чего банк сможет доказать свою непричастность в случае платежа, от которого подписант клиента в последствии вдруг станет отказываться?


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

      Навязывание поддельного документа, подписанного на приватном ключе ЭП клиента, будет заблокировано сервером, если клиент собственноручно не подтвердил эту операцию на Антифрод-терминале. Если клиентская сторона отправит серверу ДБО только подписанный документ без подписанного журнала операций, а сервер исходя из заложенной бизнес-логики будет ожидать наличия журнала, это также будет расцениваться как активность вредоносного ПО, и операция будет заблокирована.

      Что касается доказательств о причастности или непричастности. Обеспечение неотказуемости – это одна из основных задач электронной подписи. По закону, если есть документ, подписанный ЭП клиента, и выполнены условия 63-ФЗ “Об электронной подписи”, предъявляемые к соответствующему типу подписи, то такая подпись приравнивается к собственноручной. Если клиент хочет оспорить подпись, он идёт в суд, и решение принимает суд.
      Журнал операций, из которого будет следовать, что клиент собственноручно подтвердил операцию подписания на Антифрод-терминале, будет выполнять роль дополнительной доказательной базы в суде.
      При выдаче терминала клиенту с ним заключается соглашение о признании ЭП формируемой терминалом равнозначной собственноручной подписи и прописывается порядок разбора конфликтной ситуации. Такая подпись будет являться усиленной неквалифицированной в соответствии с 63-ФЗ “Об электронной подписи”. В соглашении также прописывается открытый ключ терминала, соответствующий его закрытому ключу.

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


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