プリント・スキャン及びファックスの機能を一体化した複合機 (multi-functional peripherals, MFP) は、Fig. 1のように顧客のPCや取引先のファクシミリなどのさまざまなネットワーク機器と、SMB (Server Message Block) やSMTP (Simple Mail Transfer Protocol) などのさまざまなネットワークプロトコルにより通信している。

　近年、ネットワークセキュリティーインシデント事例は、年々増加しており、特にランサムウェアによる被害が増えている。サイバー攻撃の手口はアカウント侵害と脆弱性の悪用によるものが多く確認されており、サイバー攻撃の中でもサプライチェーン攻撃は、深刻な被害につながりやすい傾向がある。複合機は顧客情報や取引先情報を所有しているため、サプライチェーン攻撃を受けた場合、自組織だけでなく、関係先への点検や対応要請が求められることになる。サプライチェーン攻撃の被害組織の中には、海外拠点への攻撃が、本社と子会社9社に連鎖した事例もある。

　本稿のNICFUM開発では、ネットワークセキュリティーにスピーディーに適合するための技術内容を説明する。

　Fig. 2に複合機ファームウェアのブロック図を示す。本ファームウェアは、有線LAN及び無線LAN経由でネットワークパケットの入出力を制御するNICFUMと、スキャナーから原稿を読取るスキャン入力部と、画像を印刷するプリント出力部と、ジョブや複合機の状態を管理する複合機管理部と、操作パネルやPC画面に表示する表示部から構成される。

　複合機管理部のJobでは、ネットワーク経由で受信したプリントジョブや、スキャナーで読み取られたスキャン送信ジョブが管理される。また、MIBやIPPでは、複合機の状態や能力が管理される。

　Fig. 3にNICFUMのファームウェアブロック図を示す。NICFUMは大きく分けて、デバイスドライバ、各プロトコルスタック、MIO API (各プロトコルで送受信されたパケットデータにアクセスするAPI) の3つに分かれている。デバイスドライバでは、有線LAN又は無線LANデバイスを制御し、ネットワークパケットの入出力を行う。各プロトコルスタックでは、ネットワークパケットをLPR (Line Printer Daemon Protocol ) やSMBなどの通信規約に基づき、通信制御を行う。MIO APIでは、送受信されたネットワークパケットからジョブ情報や認証情報などを抽出し、表示部や複合機管理部とやりとりする。

　NICFUM開発において、開発効率を向上させる施策について説明する。

　プリントジョブを受信するネットワークプロトコルは、LPRやIPP (Internet Printing Protocol) などさまざまな種類のプロトコルがあるが、ジョブを制御する開発者がこれら複数のプロトコルを把握して開発すると、開発効率が悪い課題があった。Fig. 4のようにMIO APIでは、プリントジョブを受信する処理はmioRecv()関数で複数のプロトコルを共通化し、同様にスキャンジョブを送信する処理はmioSend()関数で共通化することで、MIO APIを使う開発者は、ネットワークプロトコルを意識することなく、共通関数の引数にプロトコル種類をmioRecv(LPR)のように指定するだけで、スピーディーに開発できるようにした。

　ファームウェアのデバッグ手法は、ブレークポイント又は、ログの標準出力が一般的である。ネットワークを介して複数の通信相手とネットワークパケットの送受信を制御するファームウェアをデバッグする際は、プロトコルのシーケンスがどのフェーズまで進んでいるか知ることが重要であるが、ブレークポイントによる一時停止や、大量パケットのログ標準出力による無駄な時間によって、シーケンスタイムアウトが発生してしまい不具合が解析できない課題があった。また、パフォーマンスに影響を与えないようにログをバッファーに出力してから標準出力も考えられるが、複合機のような組み込みソフトウェアはリングバッファーのサイズが小さいため常時ログを出力すると、Fig. 5のように解析に必要なログが上書きされてしまう課題があった。

　MIOトレースでは、ログサイズを小さくするため、エラー、警告、通常の3種類のログレベルと、SMB送信やLPR受信などネットワーク機能の種類を指定することで、不具合解析に必要な最小限のログのみをバッファーへ出力するようにした。また、不具合が発生する手順を実施する前にmioSetTraceコマンドを標準入力することにより、Fig.6のように解析に必要なログが上書きされないようにした。

　複合機の市場は、オフィスで使用されるA3機や家庭で使用されるA4機、商業印刷で使用されるプロダクションプリント機とさまざまであり、要求される機能のニーズが異なる。例えば、プロダクションプリント機では印刷速度が要求されるため無線LANのニーズは無く、A4機では企業内のIPネットワークで使用されるIPファックス (SIP/T.38) のニーズは無い。また、過去使用されていたが現在使用されなくなったAppleTalkやNetWare、SLPなどの古いプロトコルはセキュリティーの観点で狙われやすいため無効化することが求められる。

　NICFUMは、機能単位で有効・無効を切り替え可能なモジュラリティーの構成をしており、市場のニーズに合わせて最適な機能をスピーディーに複合機製品群へ搭載できるようにした。

　複合機と通信するネットワーク機器は、WindowsやMac、Linuxなどさまざまな種類の環境があり、通信するネットワークプロトコルの種類も多く存在する。それらの多くの環境とプロトコルを手動で評価してしまうと、膨大な工数がかかる課題があった。

　AUTOMATION TEST TOOL (以降、ATTと呼ぶ) とは、Windowsで動作する自社で開発したアプリケーションであり、今まで手作業で評価していた下記3つの作業を自動的に行う。

1. 複合機操作 →　複合機とRS-232ケーブルで接続し、ターミナルからテストコマンドを発行
2. Windows操作 →　AutoITを呼び出し、アプリケーションやサーバーを実行
3. 結果判定 →　期待値と実行ログを比較

　Fig. 7に自動評価用PCのブロック図を用いて実施手順を説明する。事前準備として評価者はATTを実行する前にConfigファイルにServerや複合機の構成を定義する。そして、評価者がテスト開始ボタンを押下すると、Configファイルに基づきTest scriptが実行され、複合機操作やWindows操作が自動的に行われ、WireSharkで取得された実行時のパケットログと、期待値とを比較し、テスト結果を判定する。

　しかしながら、自動評価を行うに当たり、下記2つの課題が発生した。
　課題1. 複数プロジェクトの評価で使用されている共有Server環境に合わせてConfigファイルを作成する時間が多くかかっていた。
　課題2. プロトコル毎のテスト項目を実施する組み合わせ順により、正常に動作しないテスト項目が発生した。
　上記2つの課題に対して、下記2つの解決策により解決した。
　解決策1. Fig. 8のように自動評価PCの中に、自動評価専用の仮想サーバーを構築し固定化することで、Configファイルの作成時間を削減した。

　解決策2. 初期設定に戻さないと他のテスト項目実施に影響する項目があることが分かり、Fig. 9のように各プロトコルの初期設定にて変更を行った値に対して、テスト後、初期化する処理を追加した。

　その結果、10機種の複合機を全て手動評価した場合、17.7人日かかっていたところ、ATTにより4.2人日 (76%削減)に評価工数を削減した。

　最新のセキュリティー規格であるOpenSSL 3.0、SMB 3.1.1、OAuth 2.0認証の概要を紹介すると共に、複合機搭載時に発生した課題及び解決方法も説明する。これらの技術が搭載された複合機製品はFY24にリリースされる予定である。

　NICFUMは、最新のセキュリティーにスピーディーに対応するため、OSS (Open Source Software) やプロプライエタリソフトウェアのライブラリーを利用している。OSSの中でも代表的なOpenSSLは、通信データの暗号や復号、署名や検証を行うために使用される。そして、通信データの暗号化の中でも代表的なTLS (Transport Layer Security) 通信は、インターネット関連技術の標準化団体であるIETF (Internet Engineering Task Force) が定めた通信規格の1つであり、主に、Web通信やメール等のインターネット通信で使用されている。TLS通信では、暗号通信や通信相手の認証、通信内容の改ざん検知機能がサポートされ、インターネット上の安全な通信を確保している。NICFUMは最新バージョンであるTLSv 1.3をサポートしており、OpenSSL 1.0.2からOpenSSL 1.1.1へバージョンアップすることで実現している。

TLSv 1.2からTLSv 1.3の変更点を説明する。主な変更点の一つ目は、脆弱性が多く発見されたRC4、DES、3DES、SHA1等の古いアルゴリズムが削除されている。二つ目は、通信相手を認証し、暗号通信のためのアルゴリズムを決定するTLSハンドシェイクが高速化された。具体的には、Fig. 10のようにTLSv 1.2では、2往復必要であったが、TLSv1.3では、TLSハンドシェイクが1往復に削減され、高速化している。

　近年、コンピューターの処理速度は高速化し、今まで安全とされていた暗号アルゴリズムも安全ではなくなり、さらにサイバー攻撃の手法が多様化することで、脆弱性の問題は終わることがない。そのため、通信データの暗号や復号を代表するOpenSSLバージョンアップのスピーディーな対応がますます重要となってきている。そこで、Fig. 11のように複合機ファームウェアからOpenSSLを分離することで、OpenSSLの脆弱性問題が発生した時にOpenSSLのみ単独更新することでスピーディーに対応できるようにした。

4.1.1　OpenSSL 3.0パフォーマンス課題

　OpenSSL 1.1.1から、OpenSSL 3.0へバージョンアップを行った際、複合機に搭載しているWebサーバーのTLS通信時のＷebブラウザでの表示時間が30%低下する問題が発生した。この問題を解決するためにOpenSSL 3.0へ渡すデータをキャッシュする対応を行うことで、OpenSSL 1.1.1使用時と同等の通信パフォーマンスを達成した。

4.1.2　SMB3.1.1パフォーマンス課題

　米国連邦政府関連機関などのセキュリティーレベルの高い組織で複合機を使用するためには、FIPS 140-3 と呼ばれる暗号ライブラリーに関するセキュリティー要件の仕様を規定する米国連邦標準規格に認証された暗号ライブラリーを搭載する必要があり、自社の複合機はSafeZone暗号ライブラリーを搭載している。OSSであるChromiumウェブブラウザやNginxウェブサーバーは、OpenSSLのAPIを使用してTLS通信機能を実現しており、同様に、SMB 3.1.1のプロトコルスタックを実装したプロプライエタリソフトウェアのYNQも、OpenSSLのAPIを使用してSMB暗号やSMB署名の機能を実現している。しかしながら、YNQをNICFUMへ組み込むに当たり、SMB通信でスキャンデータを共有フォルダへ送信した際にパフォーマンスが遅くなる課題が発生した。特にAES-128-CMACやAES-128-GMACでデータを暗号化した場合は、顕著に遅くなった。

　OpenSSLを調査した結果、Fig. 12のようにOpenSSLのAPIを使用しなくても、SafeZoneのAPIを直接呼ぶことで、SMB暗号やSMB署名の機能を実現できることが判明したため、SafeZoneのAPIを直接呼ぶように変更した。

　その結果、Fig. 13のようにSMB署名有かつ暗号化なしのスキャンデータ送信と、SMB署名有かつAES-128-CMAC暗号のスキャンデータ送信の通信パフォーマンスが改善された。

　OAuthとはアクセス制限のあるリソースに対するアクセス許可を行うための仕組みである。2023年11月時点においては、2012年にRFCとして規定されたOAuth 2.0が最新版となっている。OAuth 2.0は以下の役割が存在する。

　・リソースオーナー：リソースの所有者

　・リソースサーバー：リソースを保持、管理しているサーバー

　・クライアント  　：リソースに対して操作を行うクライアント

　・認可サーバー  　：リソースへのアクセストークンを発行するサーバー

Fig. 14のようにOAuth 2.0の基本的な動作順は以下の通りである。

　①　クライアントは認可サーバーに対してリソースへの操作権限を要求する。

　②　認可サーバーはリソースオーナーに対してクライアントによるリソース操作を許可するか問い合わせる。

　③　リソースオーナーは認可サーバーからの要求を確認して承認する。

　④　認可サーバーはクライアントに対してアクセストークンを発行する。(アクセストークンはリソースに対して可能な操作種類や有効期限の情報が含まれる)

　⑤　クライアントはリソースサーバーに対してアクセストークンを渡してリソースへの操作許可を要求する。

　⑥　リソースサーバーはアクセストークンを検証して、問題なければクライアントの要求を受け入れる。

　従来のユーザーID／パスワードによる基本認証と、OAuth 2.0のアクセストークンによる先進認証との違いを説明する。従来の基本認証の場合、クライアントからサーバーへ情報を要求する場合、本当にユーザー操作によるものか、悪意のある第三者によるものかが判別できなかった。OAuth 2.0の先進認証では、クライアントから認可サーバーへアクセストークンを要求し、認可サーバーはユーザーへ発行の可否を確認し、許可を得たらクライアントへアクセストークンを渡すため、ユーザーの意思に基づくアクセスであることが証明できる。

　また、アクセストークンには許可する操作種類や有効期限が限定されているため、万が一アクセストークンが漏洩しても、ユーザーID／パスワードが漏洩した場合に比べてセキュリティーリスクが低い。

4.2.1　複合機へOAuth2.0の搭載

　2022年2月に、Google/Microsoftがセキュリティー向上のため基本認証を廃止しOAuth 2.0に移行するとアナウンスがあり、複合機においてもGoogle/Microsoftのアカウントを使用したe-mail送信の際に、OAuth 2.0の搭載が必要となった。複合機に搭載する場合、Fig. 15のようにリソースはe-mail、リソースオーナーは複合機ユーザー、リソースサーバーはe-mailサーバー、クライアントは複合機となり、複合機がe-mail送信を実行する際のMail Serverに対する操作認可にトークンが使用される。

4.2.2　複合機へ搭載時の課題と施策

　複合機のe-mail送信機能は、ユーザーによるスキャンデータの送信の他に、複合機自身によるカウンター情報などの自動送信機能もある。複合機自身による自動送信の場合は、実行時に複合機の前にユーザーがおらずアクセストークン発行の承認ができない課題があった。この課題を解決するために、自動送信機能を設定する時に取得するアクセストークンに加え、リフレッシュトークンも取得しておき不揮発メモリへ記憶する。そして、実際にe-mail送信実行時に、リフレッシュトークンを使ってアクセストークンを再発行し、再発行されたアクセストークンを使用して自動送信機能を実現した。さらに、リフレッシュトークンの有効期限も無期限ではないため、一定期間使われないと失効されてしまい自動送信機能が失敗してしまうという問題が発生したため、前回のリフレッシュトークン取得から一定期間後に、自動でアクセストークンを再発行すると共にリフレッシュトークンの有効期限を延長する、という仕組みも新たに搭載した。

　以上より、NICFUMは最新のセキュリティーに対応したライブラリーを効率よく開発することで、最新のセキュリティーにスピーディーに適合し、機能単位で有効・無効を切り替え可能にしたモジュラリティー構成により幅広い複合機製品群をスピーディーに提供できるようにした。

　今後は、単独バージョンアップ可能なライブラリーの対象を広げて、WebSocketやKerberosなどのライブラリーも単独バージョンアップ可能な構成にしていく。