Я расскажу о тонкостях внедрения электронной цифровой подписи (ЭЦП) в информационные системы (ИС) на базе веб технологий в контексте Национального Удостоверяющего Центра Республики Казахстан (НУЦ РК).

В центре внимания будет формирование ЭЦП под электронными документами и, соответственно, NCALayer предоставляемое НУЦ РК криптографическое программное обеспечение. В частности уделю внимание вопросам связанным с UX и объемом поддерживаемого функционала NCALayer.

Процесс разделю на следующие этапы:

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

Формирование неизменного представления подписываемого документа

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

Рассмотрим простой пример документы хранятся в виде записей в базе данных. Для подписания документа необходимо сформировать его представление в виде единого блока данных (конечно можно подписывать каждое поле записи поотдельности, но обычно так не делают), сделать это можно, к примеру, следующими способами:

• извлечь все поля записи, привести их к строкам и соединить в одну строку;
• сформировать XML или JSON представление;
• сформировать PDF документ на базе шаблона с каким-то оформлением содержащий данные из записи;
• и т.п.

Далее возможны два сценария каждый из которых имеет свои подводные камни:

• ИС не хранит сформированного представления и каждый раз для проверки подписи под документом (в частности проверки неизменности данных) формирует его;
• ИС хранит сформированное представление и использует его для проверки подписи.

В том случае, если ИС не хранит сформированного представления, разработчикам необходимо гарантировать что в будущем формируемые представления будут бинарно идентичны тем, которые были сформированы в первый раз не смотря на:

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

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

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

Подписание документа в веб интерфейсе с помощью NCALayer

Для формирования цифровых подписей на стороне клиента НУЦ РК предоставляет единственный инструмент сертифицированное программное обеспечение NCALayer которое представляет из себя WebSocket сервер, запускаемый на 127.0.0.1, которому можно отправлять запросы на выполнение криптографических (а так же некоторых смежных) операций. При выполнении некоторых операций NCALayer отображает диалоговые окна то есть берет часть работы по получению пользовательского ввода на себя.

Описание API NCALayer доступно в составе комплекта разработчика. Для того, чтобы поэкспериментировать со взаимодействием с NCALayer по WebSocket можно воспользоваться страницей интерактивной документации KAZTOKEN mobile (KAZTOKEN mobile повторяет API NCALayer).

Взаимодействовать с NCALayer из браузера можно напрямую с помощью класса WebSocket, либо можно воспользоваться библиотекой ncalayer-js-client которая оборачивает отправку команд и получение ответов в современные async вызовы.

Замечу что весь основной функционал NCALayer доступен в модуле kz.gov.pki.knca.commonUtils, использовать модуль kz.gov.pki.knca.applet.Applet (наследие Java аплета) не рекомендую, так как, на мой взгляд, это не даст никаких преимуществ, но шансов выстрелить себе в ногу с ним больше к примеру можно случайно разработать интерфейс который не будет поддерживать аппаратных носителей (токенов или смарт-карт) с несколькими ключевыми парами.

Модуль kz.gov.pki.knca.commonUtils берет на себя взаимодействие с пользователем связанное с выбором конкретного хранилища, которое нужно использовать для выполнения операции (так же он берет на себя выбор конкретного сертификата и соответствующего ключа, а так же ввод пароля или ПИН кода), но ему необходимо указать какой тип хранилищ нужно использовать. Типы хранилищ стоит разделить на два класса:

• файловые, поддерживается единственный тип заданный константой 'PKCS12',
• аппаратные (токены и смарт-карты), для перечисления тех типов, экземпляры которых в данный момент подключены в ПК пользователя, следует использовать запрос getActiveTokens.

Таким образом для того, чтобы предоставить пользователю возможность работать с любым поддерживаемым NCALayer хранилищем, можно воспользоваться одним из следующих подходов:

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

Для подписания данных рекомендую использовать следующие запросы (опять же чтобы снизить вероятность выстрела в ногу):

• createCAdESFromBase64 вычислить подпись под данными и сформировать CMS (CAdES);
• createCMSSignatureFromBase64 вычислить подпись под данными, получить на подпись метку времени (TSP) и сформировать CMS (CAdES) с внедренной меткой времени;
• signXml вычислить подпись под XML документом, сформированную подпись добавить в результирующий документ (XMLDSIG);
• signXmls аналогично signXml, но позволяет за один раз подписать несколько XML документов.

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

Модуль kz.gov.pki.knca.commonUtils поддерживает следующие типы сертификатов:

• 'AUTHENTICATION' сертификаты для выполнения аутентификации;
• 'SIGNATURE' сертификаты для подписания данных.

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

Упрощенный пример подписания произвольного блока данных с использованием ncalayer-js-client:

async function connectAndSign(base64EncodedData) {  const ncalayerClient = new NCALayerClient();  try {    await ncalayerClient.connect();  } catch (error) {    alert(`Не удалось подключиться к NCALayer: ${error.toString()}`);    return;  }  let activeTokens;  try {    activeTokens = await ncalayerClient.getActiveTokens();  } catch (error) {    alert(error.toString());    return;  }  const storageType = activeTokens[0] || NCALayerClient.fileStorageType;  let base64EncodedSignature;  try {    base64EncodedSignature = await ncalayerClient.createCAdESFromBase64(storageType, base64EncodedData);  } catch (error) {    alert(error.toString());    return;  }  return base64EncodedSignature;}

Проверка подписи на стороне сервера

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

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

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

Выполнять проверки необходимо с применением сертифицированных средств, к примеру с помощью библиотек входящих в состав комплекта разработчика НУЦ РК, либо можно воспользоваться готовым решением SIGEX.

Подготовка подписи к долгосрочному хранению

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

Для фиксации момента подписания принято использовать метки времени TSP. Метку времени на подпись можно получить либо на клиенте (запрос createCMSSignatureFromBase64 интегрирует метку времени в CMS), либо на сервере. Метка времени позволит удостовериться в том, что момент подписания попадает в срок действия сертификата.

Для того, чтобы удостовериться в том, что сертификат не был отозван в момент подписания, следует использовать CRL или OCSP ответ. Этот нюанс и рекомендации по реализации описаны в разделе APPENDIX B Placing a Signature At a Particular Point in Time документа RFC 3161.

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

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

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

Речь будет идти о сертификатах ЭЦП, выпущенных НУЦ РК.

Задачу я сформулирую следующим образом: на основе заранее согласованного шаблона сформировать в веб интерфейсе электронный документ, предоставить возможность подписать его ЭЦП, передать его для обработки группе менеджеров и обеспечить юридическую значимость в соответствии с законодательством РК.

Я буду использовать:

• Vue.js для удобства разработки (постараюсь не писать ничего специфического, так, чтобы можно было легко переключиться на любой другой);
• Bootstrap для базового оформления (его практически не будет заметно);
• axios для упрощения сетевого взаимодействия;
• pdfmake для создания PDF из JS;
• ncalayer-js-client для взаимодействия с NCALayer;
• SIGEX для проверки подписей и отправки документов по электронной почте.

Для реализации мне потребуются:

• шаблон электронного документа, состоящий из фиксированной части и полей, которые должен заполнять пользователь;
• действующий сертификат ЭЦП НУЦ РК;
• установленный NCALayer.

В самой статье я приведу только ключевые части кода, а с полной реализацией можно ознакомиться тут: https://github.com/sigex-kz/example-sign-web-form

Веб форма

В первую очередь размещу на странице веб форму, в которую пользователи будут вводить данные:

<form v-on:submit.prevent="compilePDF">  <h2>{{ formHeader }}</h2>  <p>{{ formIntro }}</p>  <div v-for="formItem in formItems" class="form-group">    <label>{{ formItem.label }}</label>    <input v-model="formItem.value" type="text" class="form-control">  </div>  <button type="submit" class="btn btn-primary">Сформировать документ</button></form>

Фиксированные части формы буду заполнять в объекте данных Vue.js для того, чтобы их можно было использовать и в HTML и в PDF:

new Vue({...  data: {    formHeader: 'Документ 1',    formIntro: 'Этот документ сформирован в браузере из данных веб формы, является примером, он никого ни к чему не обязывает и ничего не гарантирует, несмотря на то, что он может быть подписан ЭЦП.',    formItems: [      { label: 'Первый вопрос', value: '', },      { label: 'Второй вопрос', value: '', },      { label: 'Третий вопрос', value: '', },    ],...  },...

Генерация PDF в JS

Для формирования PDF воспользуюсь библиотекой pdfmake, она создает PDF файл из определения объекта JS.

Сначала сформирую объект определения и наполню его данными, после этого передам его в pdfmake и получу байты PDF файла в base64 кодировке:

async compilePDF() {  const pdfDefinition = {    content: [      { text: this.formHeader, fontSize: 20, bold: true, alignment: 'center', margin: [ 0, 0, 0, 20 ] },      { text: this.formIntro, fontSize: 15, margin: [ 0, 0, 0, 20 ] },    ],  };  for (const formItem of this.formItems) {    pdfDefinition.content.push(`${formItem.label}: ${formItem.value}`);  }  this.dataB64 = await new Promise((resolve) => {    const pdfDocGenerator = pdfMake.createPdf(pdfDefinition);    pdfDocGenerator.getBase64(resolve);  });},

Подписание PDF цифровой подписью

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

<p>Вы подписываете документ <a v-bind:href="`data:application/octet-stream;base64,${dataB64}`" target="_blank" v-bind:download="title">{{ title }}</a>.</p>

НУЦ РК предоставляет сертифицированное средство ЭЦП приложение NCALayer, его и буду использовать для формирования подписи. NCALayer это WebSocket сервер, чтобы не писать обработку отправки и получения команд вручную, воспользуюсь библиотекой ncalayer-js-client.

NCALayer поддерживает, как файловые хранилища ключей ЭЦП, так и защищенные аппаратные хранилища (токены и карты). Чтобы не перегружать пользователя излишними вопросами в первую очередь спрошу обнаружил ли NCALayer аппаратные хранилища. В том случае, если аппаратных хранилищ не обнаружено, переключусь на файловое:

const storageTypes = await this.ncaLayer.getActiveTokens();if (storageTypes.length == 0) {  this.storageType = 'PKCS12';} else {  this.storageType = storageTypes[0];}

Теперь можно подписать PDF. В зависимости от типа запрошенного хранилища, NCALayer отобразит соответствующий пользовательский интерфейс и завершит процедуру:

const signature = await this.ncaLayer.createCMSSignatureFromBase64(this.storageType, this.dataB64);

В том случае, если все прошло хорошо, на данный момент у меня имеются:

• электронный документ в виде PDF файла;
• цифровая подпись под электронным документом.

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

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

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

let response = await axios.post(  `${this.sigexURL}/api`,  {    title: this.title,    description: this.description,    signature,    emailNotifications: { to: ['some-manager@example.kz', this.email] },  },);this.sigexId = response.data.documentId;

Я запрошу отправку уведомлений не только своим коллегам менеджерам, но так же на тот адрес, который указал пользователь, так как пользователю подписанный электронный документ тоже может быть нужен.

Вторым этапом передам сервису на проверку подписанный документ:

const dataToSend = Uint8Array.from(atob(this.dataB64), c => c.charCodeAt(0)).buffer;response = await axios.post(  `${this.sigexURL}/api/${this.sigexId}/data`,  dataToSend,  {    headers: { 'Content-Type': 'application/octet-stream' },  },);

Сервис не хранит самих подписанных документов, только электронные подписи под ними. Электронные документы будут отправлены по электронной почте на указанные адреса.

Итог

Проверим соответствие поставленной задаче:

• на основе заранее согласованного шаблона сформировать в веб интерфейсе электронный документ реализовано в виде статической веб страницы и небольшого количества JS кода;
• предоставить возможность подписать его ЭЦП реализовано с использованием рекомендуемого сертифицированного ПО;
• передать его для обработки группе менеджеров реализовано путем отправки подписанных документов на электронный адрес ответственных менеджеров;
• обеспечить юридическую значимость в соответствии с законодательством РК реализовано с помощью API сервиса SIGEX.

У нас было двое взрослых, двое сопливых детей, закрытые города, полсотни тысяч заражённых, отличный темп распространения коронавируса, родители в группе риска, дефицит лекарств, а так же платные бригады скорой, коллапс медицины на юге страны и один УФ-рециркулятор в запасе. Не то чтобы это были необходимые условия для полноценного домашнего карантина, но если эпидемия накрыла с головой, становится трудно остановиться. Единственное, что вызывало у меня опасение это ультрафиолет. Ничто в мире не бывает более суровым, бескомпромиссным и порочным, чем хорошая доза 253,7 нм. Я знал, что рано или поздно мы перейдем и эту черту.
(классика)




Если же подойти к теме чуть серьёзнее, то вопрос обеззараживания воздуха возник в нашей семье намного раньше. В целом, маленькие дети более склонны к простудам и прочим ОРВИ, а когда детей несколько шанс что один заразит другого приближается к единице. Ну и мы с супругой иногда получали свою дозу вирусных частиц, подтирая детские сопли и сбивая ночами температуру. Не всегда, конечно, заболевали, но бывало (не знаю, насколько это норма, или это нам так не везло...). Но дети немного подросли, да и вопрос с нормальной вентиляцией в квартире был успешно решён, так что проблема организации правильного карантина стала не так актуальна до недавнего момента, когда вторая волна коронавируса (а может и запоздалая первая) накрыла Казахстан во всю мощь
И вот в этот самый момент мы решили включить паранойю немного подстраховаться и подготовиться к возможному домашнему карантину. И если с запасом лекарств и туалетной бумаги здравого смысла всё было более-менее нормально, то вопрос обеззараживания воздуха оставался открытым.

Стерилизуй это!

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

Смертность под воздействием УФ-излучения определённой длины волны для бактерий в целом (синий) и отдельно для кишечной палочки (красный). [Osram]

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

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

Если говорить о стерилизации воздуха, то для разных типов (медицинских) помещений существуют нормируемые уровни бактерицидной эффективности:

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

В качестве тест-организма там использовался золотистый стафилококк, но вирусы гриппа ( и коронавирусы?..) имеют схожую устойчивость. Из таблицы видно, что для жилых помещений вполне можно ориентироваться на III-IV категорию, т.е. требуемая бактерицидная доза менее 200 Дж/м3. Пока что запомним эту цифру, далее мы к ней вернёмся. Для желающих ещё больше углубиться в расчёты, есть американские данные с лампами фиксированной мощности.

Ближе к делу!

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

Изучая рынок, с удивлением обнаружил подходящее устройство у компании Вакио, где я пару лет назад брал комнатные рекуператоры. Т.к. мой опыт взаимодействия с ними был положительным, решил эту штуку и попробовать:

Вот такой прибор, принцип работы довольно прост. Это версия на 60м3/ч. Есть ещё на 120м3/ч там ещё +2 лампы и +1 вентилятор

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

Внутри много полированного металла (не какая-то алюминиевая фольга, а полноценная нержавейка). Качество внутренних поверхностей очень важно, т.к. от этого зависит бактерицидная эффективность рециркулятора (больше внутренних отражений более полно используется доступное УФ-излучение):

Не идеальное зеркало, конечно, но очень хорошо. Маленький Инженер оценил.

Минус такой хорошей полировки остаточное излучение немного просачивается наружу. Не сильно, но всё же снимать решётку-дефлектор и заглядывать внутрь не стОит:


При работе шумит. Хорошо слышно вентилятор, хоть он и висит на резиновых втулках. Производитель заявляет менее 45 дБа, для кого-то это будет много. Но, думаю, что в случае реальной необходимости, шум будет меньшим злом. Хотя кому как

Доверяй, но проверяй!

До силовой части я добраться не смог вся внутренняя часть прибора это цельный (!) лист полированного металла, хитро подрезанный и согнутый как картонная коробка. Прям реально круто! Но ломать я ничего не стал, поэтому пока что без Geek porn.

Однако про используемые лампы и вентилятор мне есть что рассказать. С последнего и начнём: насколько я смог выяснить, в приборе используется что-то вроде SUNON MA2082HVL

Для фактического измерения пришлось сколхозить воздуховод для выравнивания потока (чтобы сделать его ламинарным для более точных измерений):

Замер проводился на расстоянии 1,5 м от вентилятора.

Итого, намеряно чуть менее 40м3/ч. Меньше чем заявлено, но и система измерения была не идеальна. Учитывая характеристики вента, думаю фактическая производительность должна быть в районе 50м3/ч.
В общем нужно было мне выбирать версию на 120 м3/ч, тем более, что по цене она не сильно дороже. Ну да ладно, этой производительности для моих задач тоже должно хватать.

С лампами всё проще используются 2 либо 4 штуки HNS 15 W G13 OFR от фирмы Osram. Версия OFR это безозоновые лампы, бОльшая часть излучения которых приходится на ~254 нм:

Спектральное распределение мощности безозоновых ламп [Osram]

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

Пример скорости деградации безозоновой лампы на 55 Вт. Для используемой в приборе 15 Вт лампы я не нашёл такой график, но данные указаны такие: спад бактерицидного потока на 12% после 5000 часов и на 20% после 8000 часов.

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


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

Итого, с двумя лампами по 4,9 Вт бактерицидного потока и замеренной производительностью 39 м3/ч, я начитал 241 Дж/м3. Даже если фактическая производительность будет в районе 50 м3/ч, то всё равно имеем 188 Дж/м3, что даёт гарантированное 95% обеззараживание воздуха. При свежих лампах и нормальном напряжении в сети, (коэффициент запаса минимален или отсутствует) можно рассчитывать на 99% обеззараживание. Что, собственно, производитель и декларирует.

Слабоумие и отвага!

Ладно, прибор работает, но нам ведь хочется бОльшегО! Что ещё можно придумать, если под рукой есть мощные УФ-лампы в удобном корпусе?..

Ну, во-первых, можно сделать УФ-прожектор. Задняя стенка прибора полностью снимается (откручиваем 6 болтов), рециркулятор ставится на подставку и направляется в нужную сторону. Вполне себе замена кварцевой лампе для обеззараживания помещения. (только пожалуйста, включайте его через удлинитель...)

Во-вторых, внутри есть достаточно места, чтобы разместить средних размеров смартфон и стерилизовать его поверхность (лучше без чехла!):



На этом моя фантазия закончилась, так что если у вас есть мысли как ещё использовать такое устройства дома прошу поделиться в комментариях.

Выводы

В упомянутой статье об УФ-дезинфекции, автор делает вывод о бесполезности закрытых рециркуляторов. Мои выводы иные.
При небольшом помещении (комната 12-18 м2) подобный рециркулятор (тем более версия на 120 м3/ч) может обеспечить постоянное обеззараживание воздуха, даже с работающей вентиляцией.

Бонус

Уже начав писать эту статью, получил от производителя ссылку на их новый продукт, который только готовится к выходу. Мощная система очистки воздуха, рассчитанная на 100 м2 площади:


Ну и в заключение небольшой опрос. Насколько эта тема интересна и актуальна (или это я один такой любитель перестраховаться):