日記帳だ! with Tux on Libserver

二度目の大改造!! 日記帳…か?を継承し、より柔軟でパワフルなBlogに変身しました。

RSSに対応しています。リンク・コメント・トラックバックは自由にしていただいてほぼ問題ありません。
RSS購読方法、僕のリンク・コメント・トラックバックについての考えを読むことをおすすめします。

<< 過去

社外からもアクセス出来るようにした

在宅勤務をする人が増えて、システムが逼迫しているので、

一部のサービスを画面転送ではなく、直接インターネットアクセスで使えるようにしたとか。

期間限定の暫定措置で、追加の手続きが必要だそうだが。


この背景には社内のメールサーバーの老朽化対策で、Microsoft Exchange Online を導入したというのがあったはず。

毎月、給与明細をプライベートのE-mailに転送しているわけだけど、

以前は、社内のサーバーをポップして、社外に出ていたのだが、現在はMicrosoftのサーバーから始まっている。

Microsoftがオフィススイートとともに、メールサーバーなどセットで提供してくれるなら、乗っかった方が良しとなったんだろう。

こういう会社は多いんだろうと思う。


従来の仕組みだと、社内ネットワークからじゃないとメールサーバーへのアクセスができないようにしてたはず。

ただ、現在の方式では、社内ネットワークからアクセスしても、インターネットに出て、社外にあるMicrosoftのサーバーにアクセスすることになる。

しかしながら、認証方式が社内ネットワークに接続されていることを前提になっている。

そのため、Microsoft Exchange Onlineになっても、社外からは画面転送などを使って、社内からアクセスする必要があった。


でも、技術的には社外から直接メールサーバーにアクセスすることは可能である。

なにしろMicrosoftのメールサーバーにとっては、社内も社外も等しくインターネット経由のアクセスだからである。

ただし、認証方式については、社内ネットワークからアクセスする場合と同じでは不十分であろうと。

ここだけ手を加えれば社外からMicrosoftのメールサーバーなどに直接アクセス出来るようになったわけである。


ここまで読んでいたのかわからないけど、あらかじめいろいろな仕込みはされてたんだなと。

そもそもリモートアクセスについては、在宅勤務制度ができる以前から、管理職限定で現在の方式とほぼ同じものが提供されていた。

もともと管理職限定

いつからだったんだろ? でも僕がこの会社に入る以前のことのような気がするな。

その実績が管理職以外の在宅勤務につながっている。それが3年前のことかな。

そこから、在宅勤務が使われていく中で、制度面での不都合も埋められてきている。


メールサーバーの件はMicrosoftの方針によるところもあるが、乗っかれるところは乗っかって、功を奏したってことなのかなと。

将来的には、社内・社外問わずに同じように使えるようになることを想定していたのかもしれない。

ただ、そのためにはセキュリティ面の体制をきちんと整えないとならんかったんだけどね。

今回はあくまでも暫定措置だが、今回のことをきっかけにして環境整備が進むようになるのかもね。

画面転送方式のリモートアクセスは、導入が容易なわりに利便性が高くて評判だったのだが、

メールの送受信をするのに、スマートフォンにPCのメーラーの画面が転送されてくるなど、画面転送ゆえの不都合もあった。

そういう不都合が改善できればよいなと思うけど、どうだろうかね。


もっともハードウェアが絡む仕事だと、なかなか在宅勤務ってわけにもいかないけどねぇ。

そこはメンバー間で仕事内容を調整して乗りきるってところですかね。

家庭の事情、健康上の都合で出勤できないのは仕方ないですからね。

出来る人がやるしかない。逆に在宅でできる仕事はお願いしてもいいんだろうが。


Author : Hidemaro
Date : 2020/03/02(Mon) 23:13
コンピュータ・インターネット | Comment | trackback (0)

人工知能がする高解像度化

最近、「Remini」というアプリが話題になっていたので試していた。

高画質化アプリ『Remini』が話題! 昔の画像も綺麗に 使い方・補正度を検証 (Appliv)

人工知能により低解像度の写真を高画質化するようだ。


無償でも使えるが、処理できる枚数には限りがある。

まぁ本当は有料サービスに登録してねって話なんだろうけど、ちょっと試すだけなら。

入力は主に雑誌の先出しでWebサイトに掲載された、極端に低解像度の写真ですね。

だいたいこんな写真が掲載されますよってものなので、解像度はかなり低いんですね。


出力として得られた写真、確かに入力の解像度の低さからは想像できないほどきれいになっている。

ただ、とても違和感があって、それは顔立ちはくっきりしているのに、他がぼんやりしていたりするのである。

どうも、このReminiというアプリ、人物画像の高解像度化に特化しているように見える。

顔は入力の解像度の低さに対して、あまりにきれいに補修される。これはすごい。

肌に乗っているノイズもきれいに取り除かれる傾向にある。これもすごい。

ただ、体の輪郭がぼんやりしていたり、服の柄がぼんやりしていたり、逆に柄が除去されてしまったり。

輪郭の推定がうまくできず、手の形がおかしくなったものあった。

あと、人の顔も横顔は適用してもぼんやりしていた。横顔を推定するのは難しいんだろうな。


解像度の高い鮮明なデータとそれを劣化させたデータの対応付けを学習して、

それで解像度の低いデータから高いデータを推定しているわけだが、

当然のことながら、どんなデータで学習するかによって得られるものは違うだろうと。

そういえば、と思い出したのが「Waifu2x」だった。

無料で二次元画像を人工知能が補完してハイクオリティで1.6倍/2倍に拡大できる「waifu2x」 (Gigazine)

これはもともとイラストの高解像度化を想定したツールだった。

イラストとJPEGは必ずしも相性が良くなくて、JPEG圧縮と縮小で劣化した絵をそれらしく高解像度化するのが目的だったはず。

なお、現在はWaifu2xは写真にも適用できるようになっていて、Reminiに入力したのと同じデータを入力して比較してみたが、鮮明に高解像度化された気はしない。

一方でイラストを入力とすると、非常に鮮明に出てくるので、どこで学習したかという違いであろうと思う。

アルゴリズムも違うだろうから、学習データの違いだけでは説明できないだろうけど。


ただ、顔立ちだけでも鮮明になると写真の印象ってだいぶ変わるな、とも思いましたね。

Reminiの出力は、顔ばかり不自然に鮮明になるが、まず目に入るのはそこですからね。それでいくらかダマされる。

それ以外の部分もノイズ除去は効果的に行われている傾向はあるが、情報量が足りない分はぼんやりと再現するしかない。

うまくやってるとは思うけど、そんなもんです。


FacebookかGoogleでのログインが必要だったり、無料で使える範囲だと、枚数も限られたり。

思うところはいろいろあるが、こういうこともできるんだなぁという点ではおもしろい。


Author : Hidemaro
Date : 2020/02/27(Thu) 22:59
コンピュータ・インターネット | Comment | trackback (0)

SMS認証も万能ではないが

Yahoo!にパスワードを取り上げられた話は何度も話題にしている。

パスワードを没収されたので

その後の認証手段はSMS認証ほとんど一本である。

一応、スマートフォンのChromeではスマートログインとか、FIDOの指紋認証も使えるが、Yahooi!アプリでは非対応である。

携帯電話紛失時の対策としてPCのメールアドレスも二次的な手段として用意してるが、使ったことはない。


SMSというと、その電話番号の携帯電話でしか受信できず、通常のE-mailとは別のネットワークということで、

わりと安全性が高そうな気がするし、そこに期待しているところは多いと思うのだが、そうでもないらしい。

Reddit、ハッカーによるユーザーデータへの不正アクセスを報告 (ZDNet Japan)

これはSMS認証を突破されて不正アクセスされた結果、バックアップデータが流出したというもの。

どうもSMSインターセプトという攻撃を受けたようで、何らかの方法でSMSを傍受したらしい。

SIMカードの紛失時の再発行時の本人確認が不十分だと、こういうことができることもあるらしい。


あと、これは非常に単純な話だけど、中間者攻撃ですね。

LINEから届くSMS認証メールには「他人には教えないでください」という表記がある。

具体的にこういう攻撃が行われているということがLINE社のWebサイトで公開されている。

【注意】 SMS認証番号を聞き出す詐欺にご注意ください (LINE公式ブログ)

ここまで具体的に書いてあるのは珍しいけど、多様な利用者のいるLINEゆえの事情もあるのだろう。

ワンタイムパスワードが中間者攻撃に脆弱なのはよく知られた話である。


この問題を緩和する方法として、こんな提案があったとか。

アップルが「SMS認証」の標準化を提案。Googleはすでに受け入れ (engadget)

SMSに入力先のWebサイトとワンタイムパスワードを統一された記述方法で書いておけば、

適切なWebサイトであれば自動入力されるということらしい。

もし、フィッシングサイトがSMS認証を要求してきても、自動入力されないところでおかしいと気づけるということらしい。

といっても、PCで認証を要求して電話にSMSが届く場合など、自動入力が適用できないケースも多いだろうから、

これにどれだけの意味があるのかは疑問だけど。


SMSインターセプトについては、携帯電話会社がSIM発行時に本人確認を徹底すれば防げる部分が大きい。

日本では携帯電話に関する本人確認が徹底しているので大丈夫かなと思うけど、まぁ懸念はあるよね。

ただ、それを抜きにしても、SMSに極度に依存するのは問題が大きいのかなと。

パスワードを完全に取り上げて、SMSで届くワンタイムパスワードでログインするのって本当に得策なのって?

他の認証手段の補強に使うならまだ……とは思うけど。


いろいろ課題はありつつも、他の方法よりマシという利用でSMS認証は使われそうである。

一応、Yahoo!はパスワードレス化の本命はFIDOだと言っているんですけどね。

4500万人のユーザーに“パスワード”をやめさせたい――ヤフーが進める「もっと安全で簡単な認証」とは (1/3) (ITmediaエンタープライズ)

そういうなら、Yahoo!アプリとか、PC版WebサイトとかもFIDO対応しろよとは思いますがね。

そこは段階的対応ということなんだと思いますが、早期の対応に期待している。


Author : Hidemaro
Date : 2020/02/03(Mon) 23:39
コンピュータ・インターネット | Comment | trackback (0)

Internet Explorerのバージョンは?

たびたび話題にしているが勤務先では、WebブラウザがInternet Explorerが基本である。

ただし、社外サイト閲覧用という名目でGoogle Chromeも併用できる。(cf. Google Chromeも可になったが)

実際のところ、Internet Explorerじゃないとどうしょうもないページは社内でも限定的である。

ただ、それが業務上重要なサービスだったりするので、やっぱりInternet Explorerは手放せないのだが。


今さら知ったのだが、Windows 10に搭載されているInternet Explorer 11(Windows 7,8でも使用可)は、

ドキュメントモードとして 11,10,9,8,7,5 の6モードがあるそうだ。

それぞれInternet Explorerのバージョンを表していて、11以外は古いバージョンの互換モードである。

このBlogのように特段の指定をしておらず、なおかつ互換モードの設定もされていなければ11モードで表示される。

どのモードで表示しているかはF12で表示できる開発者ツールで確認出来る。


それで社内サイトをいくつか調べてみると、案外11モードや10モードで動いているものが多かった。

「イントラネットサイトを互換表示で表示する」の設定はされているのだが、

META要素またはHTTPヘッダで X-UA-Compatible を指定することで上書きしているようだ。

一方で、どうしてもInternet Explorerじゃないと正しく動作しないページでは、

5モードまたは7モードになっていた。これはイントラネットを互換表示にする設定や、X-UA-Compatible での指定による。

社内サイトとひとまとめにしていたが、実はInternet Explorerはいろいろ使い分けていたと。


かつてのInternet Explorerは問題も多かったが、最近は案外使えるなと思っていたところである。

もっとも勤務先で社外サイト閲覧用としてChromeが標準化された原因である、ページによってフリーズする問題は気になっていたが。

Internet Explorerの歴史を見てみると、Vistaから標準搭載となったIE7から改善が始まっている印象である。

Windows XP世代では散々という印象もあったが、Windows Vista/7世代ではそこそこという感じだった覚えがある。

もっともWeb標準への追従という点で課題が残っていたのも事実なのだが、IE11モードならけっこういけるよ。


今月、MicrosoftはブラウザエンジンがChromiumになったMicrosoft Edgeを公開したそうである。

Microsoft Edgeはもともと自社製エンジンを積んでいて、これを改良してきた経緯がある。

ただ、追っつかないという判断もあったのか、Chromiumベースに乗り換えることを決断したそうだ。

一方で、ChromiumベースのMicrosoft EdgeはIEモードを持っているそうで、

Web標準によく追従したChromiumモードと、過去のシステムで互換性を保てるIEモードが併用できるようだ。

Internet ExplorerからEdgeに乗り換えて、必要時はIEモードでとして欲しいということでしょう。


Chromiumベースってことは、Chromeと近い挙動になるんだろうと思う。

すでにデスクトップ用途ではもっともシェアが高いブラウザはChromeだという話なので、

Edgeも無難な動きをするとは思うし、その点ではありがたい話だろうと。

僕の場合、個人用途ではAndroidとのインテグレーションという観点でChromeが必要だけど、

ChromiumベースのMicrosoft Edgeでもよい人は多いだろうし、むしろIEモードがあるならそっちがよいという人もいるだろう。

これがMicrosoftにとって巻き返しになりそうな気もしますね。定かではないところも多いですが。


Author : Hidemaro
Date : 2020/01/29(Wed) 20:17
コンピュータ・インターネット | Comment | trackback (0)

工場でモバイル回線を使うらしい

とある会社の製品を見ていたら、収集したデータのアップロードにモバイル回線を使っていることに気づいた。

据え置きの機器だし、設置場所も工場内など、それなりにインフラのあるところだと思うのだが。


同社の既存の測定機器と、ゲートウェイをEthernetでつないで、それで使うらしい。

設定をすると、定期的に測定データをアップロードして、それでWebサービスでデータを確認出来ると。

確か、既存の測定機器もEthernet経由のWebアプリケーションで測定データの確認が出来たはず。

なので、これらの機器とEthernetで直接接続できる環境であれば、そもそも不要である。

もっとも、それをインターネットから見られるようにしようとすると、それはけっこう難しいと思うが。


そこでインターネット経由で測定データの確認が容易にできるように、

ゲートウェイとWebサービスをセットで提供しているというのは、それなりに意味がありそうである。

でも、どうしてモバイル回線なんだろう。

ちなみにこのモバイル回線はメーカーが契約したものをユーザーに提供しているそうである。

ゲートウェイを購入して、システムの利用契約を結ぶと、ゲートウェイはモバイルデータ回線が接続されるらしい。


なんでかなぁと思ったんだけど、自分の勤務先を考えてもわかるが、機器を社内ネットワークに接続することがまず1つハードルなんだよね。

適切なセキュリティ対策がなされているか、このソフトがインストールされているかとか。

勤務先ではOSがWindowsでなければ、対策は各管理者に委ねられている面は大いにあるが。

その上でインターネットにアクセス出来るようにするとなると、Proxyだのいろいろ設定が必要で煩わしい。

そういうのをすっ飛ばしてモバイル回線で飛ばすのは手続き上は楽だよね。

どうしても固定回線が使えないケースはあまり多くないと思うけどね。


ローカルな無線で測定データをアップロードするシステムがあって、

その長所として、動くものに取り付けても測定できるし、なんなら動きながらでも測定できるということがあった。

高所にあるとかで配線が難しいというのは容易に想像できるが、動き回るから配線が難しいというのはなるほどと。

一方でこのシステムは配線自体は可能な環境で使われるものである。

なぜならばゲートウェイの電源は商用電源から供給するからである。

無線のメリットを最大限に生かすならば、電池駆動でなければ意味は無い。(定期的な電池交換を行う必要はある)


こんな用途でもモバイル回線使うんだなぁと思ったけど、費用的にはそう高いものではないんでしょうね。

それ以上に施工費やカスタマイズ費用が削減することは十分可能でしょう。

というわけで、目からうろこだった。


Author : Hidemaro
Date : 2020/01/27(Mon) 23:26
コンピュータ・インターネット | Comment | trackback (0)

マスターパスワードなんだけど

職場のパスワード管理に悩んでいたが、最近になってよい答えがでた気がする。

ここに行き着くまでは少し大変だったが。


職場のパスワード管理の最大の問題はパスワードの定期変更である。

Windowsログインなどで使うパスワードと、もう1つ他のシステムのパスワード、

これがけっこうな頻度で変更が必要で困っていたのである。


社内システムの多くはSSO(シングルサインオン)になっているので、

Windowsログインにつかうドメインパスワード1つでほとんど済むのだが、

ごく一部に独自のパスワードを持っているものがあり、これの変更頻度が一番高いという困った話。

しかも、最近何回かのパスワードと一致すると拒否されるという、これもまためんどくさい話である。

ドメインパスワードよりも苦しんできた経緯がある。


ドメインパスワード以外の管理は、社内の自分だけがアクセスできるネットワークストレージに、

ファイルを置き、このファイル自体にもパスワード暗号化をかけるという方法にすることにした。

社内のネットワークストレージなので、社内であれば他のPCからもアクセス出来る。

アクセス制御はかかっているし、気休め程度ではあるがファイル自体も暗号化されている。

メールさえ受信できればパスワードリセットはできるわけだし、ここら辺がよい落とし所でしょう。


困ったのがドメインパスワードである。

いわば社内においてはマスターパスワードと呼べるもの。失っても忘れても大変である。

こういうのは長くて覚えやすいものがよいとよく言われる。

しかし困ったことに定期変更が必要なので、長くて覚えやすいというのはなかなか難しい。


他のデバイスにパスワードを格納するということで、内線電話に格納しようかなとか模索したが、それも厳しい。

いろいろ考えた結果、固定のパスワードの前に8文字程度を付加することにした。

定期変更のたびに、パスワードの前に付加する8文字程度を変更することにして、その付加した文字をメモに残しておけばよいと。

紙のメモと内線電話のメモの2箇所に記録してある。

付加する文字列が少ないと、定期変更しても、変更前のパスワードから変更後のパスワードを類推される恐れがある。

固定の文字列が短いと、メモを見ただけでパスワードが割れてしまう。

この方法で定期変更も安心だし、従来のパスワードより長くなったのでその点でも安心である。


普段はWindows HelloでPIN認証にしているので、パスワードを入力することはない。

勤務先のポリシーでもWindows Helloは使えたんですね。

職場でWindows Helloの顔認証を使っている人がいたが、僕はPIN認証で。

覚える気はさらさらないパスワードを使っていると、Windows Helloのメリットは大きいよね。


ただ、その一方で、在宅勤務などで自宅からリモートアクセスする場合は、ログインIDとパスワードが必要である。

なので、職場で普段働いている限りにおいては、パスワードは忘れててもあまり問題はない。

極端なことを言えば、社内では定期更新後の最初のログインと、パスワード変更時の変更前パスワードの入力のときしか使わない。

しかし、ひとたび会社を出れば、必ず必要になるということで、どうにもめんどくさいのである。

(社外からのアクセスには通常のパスワードとは別の認証手段も併用する必要がある)


僕がここで働き始めたころは、社内のシステムいくつかで独立したパスワードを持ってて、今よりはるかに手を焼いたものだが、

残りはもう1つ、それもそう遠くないうちに他のシステムに置き換えられると言われている。(本当か疑われてるけど)

さすがに置き換え後はSSOになるんじゃないかなぁ。

SSO化が進み、Windows Helloも使えるので、社内のパスワードレスに近づいているのは確かである。

問題はマスターパスワードとも言うべき、ドメインパスワードの取扱なんだよね。

会社ではいろんな人が働いているし、コンピュータの使い方もいろいろ。万能な方法はなかなかない。

着実に改善されてますよ――とだけは言っておきますけど。


Author : Hidemaro
Date : 2020/01/10(Fri) 23:20
コンピュータ・インターネット | Comment | trackback (0)

スタック領域をどうするか

たいていの場合、プログラムを動作させるにはメモリ上のスタック領域を使う。

ローカル変数や関数呼び出しや割り込みしたときのプログラムカウンタやレジスタを待避させるのに使う。

当たり前の事ながら、このスタック領域のメモリを破壊すると、その後のプログラムの動作がおかしくなる。


ただ、マイコンの低レベルなプログラムではスタック領域を破壊するようなプログラムを書くこともある。

今回はスタック領域として使うメモリ領域を含めて、メモリ全体を特定の値で初期化するというものだったんだけど。

もちろん、スタック領域を壊すわけですから、関数の呼び出し元に戻ることは想定していない。

プログラムの初期化処理で行うわけですから、一方通行でよい。

しかし、今まさに使っている領域を破壊してしまうと、その時点で動作が狂ってしまうから問題である。


こういう場合、スタックを使用しないプログラムを作ればよく、じゃあアセンブラかと思ったんだけど、

うちの職場では、そういうプログラムも他のプログラムと同じようにCで記述されている。

当時のチームリーダーに聞いたら、できたとこ勝負らしい。

簡単なプログラムならスタックを使うまでもないわけで、Cでコンパイルしてもスタックを使わないプログラムが生成されることはある。

どうもそこを狙ってるらしい。そんなのアリかよと思うけど、ちゃんとコンパイル結果は確認しているのでご安心を。


ただ、今回の初期化処理はもうちょっと複雑なので、Cで書いてはスタックを使わずとはいかない。

じゃあどうしようかと考えた結果、このマイコンにはどうしても使い道のないRAMがあることに気づいた。

使い道がないというか、とある理由によりプログラムが通常動作になってからは使えないんだよね。

ただし、初期化処理の間に使うのはあまり問題がないので、すでに初期化処理の中で使用している領域だった。

初期化処理の前にスタックポインタを変更して、終わったところで本来のRAMへスタックポインタを戻すことにした。

こうすれば、RAMを初期化するプログラムでスタックを使ってしまっても問題はない。


ちなみにスタックポインタを変更する処理はアセンブラで書かれている。

ここでは数少ないアセンブラで書かれたプログラムである。

スタックポインタを変更してしまうと、基本的に元のプログラムには戻れないということで、

スタックポインタを変更して、指定されたプログラムへジャンプするというのがセットになっている。


今回、初期化処理中だけ使えるRAMがあったのは幸いだった。

メインRAMはとある都合により、全領域を初期化しなければ安心して使えないことが判明した。

「書きつぶすと初期化処理が長くなるから現実的とは言えないのでは」とは言われたが、

とある処理に紛れ込ませれば、処理時間が伸びないだろうと考えたわけである。実際にそうなった。

ただ、そうすると、なんとなく書いてスタックを使わないプログラムが生成されるわけはないし、

そこをなんとかするためにアセンブラで書くのも気が引ける。(類似するプログラムがアセンブラだったらやってたかもしれないけど)


もしも、スタック領域のRAMも含めて書きつぶさないといけないなら、2段階に分けてやってたかもね。

スタック領域として使っている部分を避けて書きつぶしてから、

スタック領域を使わない関数で残りを書きつぶして、スタックポインタを再設定するとか。

最初はそういうやり方も考えたのだが、めんどくさいしイマイチだなぁと思ったら、

そういえば、別のRAMにスタック置いても初期化処理なら許されるなと思ったのである。


こういうのはあんまり書かないプログラムだと思いますけどね。

このプログラムも1回作ってしまえば、同じものを同種のシステムでひたすら流用する予定だし。

出来てしまえば、初期化も何も考えなくて済むってことだし。


Author : Hidemaro
Date : 2020/01/07(Tue) 22:41
コンピュータ・インターネット | Comment | trackback (0)

FIDOじゃなかった

昨日、セキュリティキーの話を書いた。

セキュリティデバイスはそうそう売ってない

セキュリティキーの用途としてSSHのログインに使うというのがある。

家にssh鍵を忘れるという概念 (hiroqn's [Data.ByteString.Lazy.ByteString])

常に持ち歩いてないとこういうことも起きるよって話。


現在、世の中で販売されているセキュリティキーはFIDO U2F または FIDO2での使用を想定したものが多い。

FIDOの認証器というのは、本人確認(UV) や ユーザーの存在(UP)を確認する機能を持っている。

AndroidやWindowsの指紋認証をすると、指紋で本人確認と存在の確認が同時にできる。

一方でセキュリティキーとして販売されているものは、センサーに触れることで、誰かが存在していることは確認出来る。

かつてのFIDO U2F(Universal 2nd Factor、すなわち2要素認証) は、セキュリティキーは存在確認さえできればよかった。

本人確認はサービス側のパスワード認証でやるから、セキュリティキーを持った人がいることさえ確認出来ればよしだったと。

一方で、指紋認証機能の付いた端末と、タッチセンサーだけのセキュリティキーを同列に並べることはできないわけで、

FIDO2では、サービスがUVを要求すれば、セキュリティキーではPINコードを併用して本人確認しなければならないらしい。


なんて書いたはよいものの、実はSSHのログインに使うセキュリティキーの機能はこれではないのだ。

実はSSH秘密鍵の格納に使っているのは、PIVモードという、スマートカード互換の方式なのだという。

秘密鍵の格納先としてICカードを使うというのはだいぶ昔からある話で、マイナンバーカードもそうだよね。

マイナンバーカードはPIV互換ではないのだが、世界的には歴史のあるシステムのようだ。

よくよく調べてみると、現在普及しているセキュリティキーでは Yubico社 の YubiKey のFIDO専用ではないものを使うのが前提らしい。


YubiKeyが搭載している機能 (ソフト技研)

FIDO U2F & FIDO2 は最初に書いた機能である。この機能だけのセキュリティキーを売っている会社は多い。

Yubico社はこの機能に限定したセキュリティキーを売っていて、定価ベースで3割安くなっている。

チャレンジレスポンスもこれに類する方式だが、YubiKey独自方式かな。

OATH-TOTPはGoogle認証システムと同じやつですね。(cf. ワンタイムパスワードとの2要素認証)

Smart Card, Open PGPはどちらも秘密鍵を格納する機能という点では同じ。SSH秘密鍵は通常これを使う。

Yubico OTPは、YubiKeyでもっとも歴史ある機能のようだ。

キーボード互換のデバイスとして認識され、センサーをタッチすると44桁のカウントベースのワンタイムパスワードが入力される。

非常に長いが自動入力なので手間がかからないということで、安全性と利便性が両立できると。

パスワードの後ろにYubico OTPを付けて送って、受け取った側で分解して(Yubico OTPは固定長)検証すればよいので、早期に普及したらしい。

OATH-HOTPとSymantec VIPも同じくワンタイムパスワードのキーボード入力、安全な静的パスワードは固定文字列がキーボード入力されるというもの。


これを見て思ったのは、YubiKeyってキーボード互換・PIV互換という既存のデバイスになる機能が特徴なのかなと。

今でこそFIDO U2FまたはFIDO2というところで、セキュリティキーの標準的な利用法が確立されたけど、

そうやって普及するまではキーボード互換でワンタイムパスワードの自動入力をしますとか、

そういうところから入らざるを得なかったのかなと。そうして切り開いてきたから今のFIDOがあるんだろうけど。

FIDOだけでよいというのなら、YubiKeyはオーバースペックでやや高価ということになる。


YubiKeyでのSSH認証の使い方を見ていると、PCで生成した秘密鍵を書き込む方式が一般的のようだ。

一回書き込んだ秘密鍵はキーの外に出せないことは保証されているが、同じ秘密鍵持ったキーを複数作ることはできるかもしれない。

マイナンバーカードと同じようにPINコードで認証して秘密鍵を呼び出すことになる。

メリットは秘密鍵を安全に運搬できること。これが全てということになろうかと思う。


FIDO用の秘密鍵をSSHの認証に使う方法ってあるのかなと調べたが、

今のところは Gravitational Teleport というWebで認証してSSHを利用するシステムでは使えるとか。

SSHそのものがFIDOによる認証に対応しているというより、中継サーバーが対応してるよって感じみたいね。

理屈上はFIDO認証器(セキュリティキーまたはAndroid・Windows)の内部で持っている秘密鍵を利用して、

それに対応する公開鍵をSSHサーバーに指定しておけば認証出来るんじゃないかという気はするんだが、

まだ、そのためのソフトウェアができていないというのが実情なのかなと。

PIV互換方式ならば、既存のソフトウェアで対応できたから、現状はそれでやってますよと。


理解してる人には当たり前かもしれないけど、ちょっとダマされた気になってしまいましたね。

言われて見れば、SSHでセキュリティキーを使うという記事で使ってるのは、どれもこれもYubiKeyだった。

一般のFIDOで使ってるセキュリティキーは 飛天(Feitian) とか他のメーカーも使用例があるんだけど。

とはいえ、複数メーカーから選べて、比較的安価なセキュリティキーを広く使いたいというニーズはあるはずで、

そのうち打開されるんじゃないかという気はしますけどね。

それができるようになると、Windows Helloで指紋認証して、SSHにログインというのも夢ではないかも知れない。


Author : Hidemaro
Date : 2019/12/18(Wed) 23:49
コンピュータ・インターネット | Comment | trackback (0)

セキュリティデバイスはそうそう売ってない

ヨドバシカメラで指紋認証器を買ってきたという話を書いたが(cf. 銀行アプリの指紋認証は使えるか)、

実は店頭に置いてあったわけではない。

入力デバイスなのかなぁとか探したんだけどないんだよね。

通販には置いてあって、しかもよく見てみると店頭受取で「30分以内にご用意いたします」となっている。

どうも店頭には並べていないが、店に在庫は置いてあるらしい。ヨドバシはそんな在庫の持ち方してるのか。

もっとも安いものだと1000円ほどである。これでも Windows Hello で使う分には全く問題ない。


Windows Hello はパスワードを使わない認証方法として 顔・指紋・PIN認証を提供している。

PIN認証ってパスワード認証じゃないのかと言われたら、知識による認証という点では確かにそうなのだが、

Microsoftアカウントのパスワードではないというところがポイントらしい。

Microsoftアカウントのパスワードが流出すると他のデバイスでもログインされかねないが、

PINコードはPINコードがセットされたPCとセットで意味を成すので、物と知識による2要素認証であるわけだ。

もっとも、このPCではローカルアカウントなので、ログインパスワードとMicrosoftアカウントのパスワードは無関係なのだが。


とはいえ、Windows Hello を使うならば、PINコードの登録は必須である。

指紋や顔を登録するならば、それと同時にPINコードも登録しなければならないのだ。

Windows Hello のPINコードは桁数も自由だし、数字に限らないので、ローカルアカウントのパスワードと同じに設定した。

指紋認証が使えないときの代替手段ですね。まぁパスワードも代替手段ではあるんだけど。

指紋認証を使うメリットはやや複雑なPINコードにしても不便でないことだと思うので、

PINコードといえば4桁の暗証番号だろうというところにとらわれない方がよいかもしれない。

実際、AndroidのPINコードは指紋認証前提に長くしてある。


今のところ、Windows Hello の用途はWindowsのログインと、Google Chromeに保存しているパスワード表示のときぐらい。

Chromeに保存されてるパスワードを他の用途に使うときにはパスワードを表示する必要があるが、

このときにWindowsの認証が要求されるので、指紋をタッチすればOKと。

複数人で使うPCだと、指紋でユーザーを判別してログインできるとか、そういうメリットもあるんだが。

今後、WindowsでもFIDOを使った生体認証が普及すれば役立つ機会も増えそうなんだが。


ところで最初の話に戻るのだが、指紋認証器とともに店に並んでるかなと期待したのがセキュリティキーである。

具体的に購入したかったわけではないのだが、セキュリティデバイスというくくりでは同じかなと。

FIDOに準拠した認証セキリティデバイス (飛天ジャパン)

これ、何なのかという話だけど、暗号鍵を内蔵したデバイスである。秘密鍵は外に取り出せないので複製できない。

例えば、Googleの2段階認証にセキュリティキーを設定すると、PCでもスマートフォンでも同じキーが接続された機器しかログインできない。

職場のPCでも、持ち歩いてるスマートフォンでも、家のPCでも、同じセキュリティキーを接続しなければならない。

なので、家の鍵のように持ち歩くことが想定されていて、それでキーホルダー用の穴があるんですね。

スマートフォンへの接続はNFCを使用することも想定されている。(USB接続でもよい)

こちらは店頭にないどころか、ヨドバシの通販にもない。Amazonなら普通に買えるみたいだけど。


この辺の品揃えを見て思うのは、セキュリティデバイスという考え方がまだ一般には普及していないということだよね。

指紋認証については、ノートPCでビルトインのものは多いが、後付けするのはあまり一般的ではないと。

ヨドバシで見る前に、秋葉原界隈の店を渡り歩いて調べてたときもそうで、だからPC自作する人もあまり興味はないんだろうと。

デスクトップPCだとビルトインはあまりないので、一般のご家庭でも使いたいというニーズはありそうだが。


セキュリティキーは、用途からすれば、気軽に買って使い始められてもよさそうだが、実際はそうなっていない。

まぁAmazonで買えば1個から即納なんで、それでよいといえばそうなのだが。

セキュリティキーを使うのは会社から言われているか、物好きかどっちかというところではないか。

インターネット時代に物理的なキーを使うというところに違和感を覚える人も多いんだろうと思う。

正直、僕もそう思っているのだが、パスワード認証だけでは厳しい実情があって、

そこに対抗するには物を使った認証が必要で、複数の機器で唯一の物を共用することを考えると、ああならざるを得ないのかなと。

まだ発展途上かなと思わなくもないが、安く気軽に持てないとなかなか広くは普及しないのかなと。

在宅勤務などで会社のリモートアクセスを使う時とかに使えると便利そうだと思ったが。その場合は会社が買うか。


Author : Hidemaro
Date : 2019/12/17(Tue) 23:54
コンピュータ・インターネット | Comment | trackback (0)

自分のサーバーに画像を置きたかった

今日は有給休暇取得推奨日だったので、家でサーバーを触ったりしていた。

ちなみに今日が推奨日なのは、12月に祝日がないから。年末年始の休日はあるんですけどね。


クラウド上に置くにははばかられるが、インターネットから自分だけ見られるようにしたい画像ファイルがあった。

もちろん適切にアクセス権を設定すれば、自分だけが見られる状態には出来るが、管理者にも読めないわけではない。

自分のサーバーに置けば、おそらく自分以外の人がファイルを触ることはできないし、

SSL証明書認証で自分だけが見られる状態を保証することもできる。

クライアント証明書で通す

これに加えてSSLRequireディレクティブで証明書のCNの条件も加えた。


サーバーに置いて、それを自分だけでHTTPSでアクセス出来るようにすること自体は難しいことではないが、

スライドショーのようにして読めるようにしないと、とても使えたものではない。

どうしたもんかなぁと思っていたら、ちゃんとそういうJavaScriptのライブラリがあるんですね。

jQuery lightgallery

他にもいろいろあるんだけど、もっとも目的にかなうのはこれだった。

サムネイルに画像ファイルへのリンクを付けたものを列挙しておいたものにライブラリを付けると、

サムネイルをクリックすると、画像が拡大されて、スライドショーが表示されるように変換されるようだ。

これを使えば、サムネイルとリンクだけのシンプルな記述で、十分に機能的なページができた。

自分しか使わないのだし、多少味気なくても機能的なら問題ないでしょう。


もう1つ気になったのが画像ファイルの容量のこと。

最初はサーバーのストレージ容量の心配をしたが、200GBもあるから余裕だった。

ただ、画像ファイルの容量削減自体は読み込みスピード向上に効果があることでもある。

写真の場合はJPEGが標準的な形式だが、より圧縮率の高い方式もあったよなぁ。

そこで調べたところ WebP というのが比較的普及しているようだ。


WebPはGoogleが開発している動画コーデックVP8を静止画に適用して作られた形式である。

Googleが普及に取り組んでおり、Google Chromeは早期に対応、Mozilla Thunderbird、Microsoft Edgeも対応した。

Internet Explorerは対応してないが、Edgeを使えばOKと考えると、Windowsであればほぼ問題ないでしょう。

もちろん、ほとんどのユーザーがChromeを使っているAndroidも問題なし。

ただ、Appleがさっぱりで Safari は未だ非対応ということで、ここがWebPの課題である。

一方でSafariは JPEG 2000 に対応してるんだよね。ただ、JPEG 2000は他のブラウザがさっぱりダメという。

今回の用途はAndroidかWindowsで、どちらもChromeでの表示を想定しているので、WebPで全く問題ないだろう。


変換ツールはGoogle自身も提供しているようだ。(cf. Getting Started (WebP))

同時に巨大な画像の縮小などの処理もやりたかったので、いろいろ探したら XnConvert に行き着いた。

Quality Factorは70にして変換したが、元のJPEGの1/4以下になった。

もっとも、元のJPEGの出力条件が最適だったわけでもないし、なにより大きい画像ファイルはリサイズしている。

Googleの資料によれば、同じ品質のJPEG画像に比べれば25~34%軽くなると書かれている。

本来の実力はそんなもので、JPEGでも適切に生成すれば1/3ぐらいの容量にはなったんだろう。

同時にサムネイルも作成した。こちらはサイズも小さいが画質も問わないのでQuality Factorは30で。さすがに汚い。

あとは、普通にサーバーに置くだけだが、/etc/mime.typesにWebPがないので追加する。

image/webp                                      webp

WebP画像について、Chrome・Firefox・Edgeでの表示においては全く問題ない。

Windowsでは、サムネイルは表示されるが関連付けはChromeになってた。

標準のフォトアプリでは表示できないが、ペイントは読み込むので全く非対応でもないらしい。作成は出来ないが。

画像編集ソフトでの対応状況は悪く、最初からWebPで出力しようというのは難しい。

SafariとInternet ExplorerがWebP非対応であることもあって、WebPへ一本化というのはまだ現実的ではなく、

一旦、JPEGで作成して、これをWebPに変換するという使い方にならざるを得ないのかなと。

あと、ユーザーにもWebPには戸惑いもあったようだ。ダウンロードしてもそれを使えるソフトが少ないからだろう。
(cf. グーグルの画像形式「WebP」を試行するFacebook--ユーザーからは不満の声も (CNET))

Safariが最後の砦なのかもしれないと思ってたが、そう簡単な話でもないのかもしれない。


こうしてサムネイルと画像へのリンクを貼ったわけだが、一部のサムネイルの読み込みに失敗する。

なんでだろうと調べたら503エラーを返しているようだ。

503エラーというと、MaxClientsで設定した値以上にアクセスがあったときに出るようだが、そんなことはないだろう。

原因は mod_limitipconnで同一IPアドレスからの接続数を制限していたからだった。

もともと MaxConnPerIP には5を指定していた。同一IPからの接続数が5を超えたら503エラーを返すと。

どうも大量にサムネイルがあると、ブラウザは大量のコネクションを張って、5コネクションを超過したようだ。

この数を緩和すると問題は解決したのだが、なんでそんな行儀の悪いことをしてるのか……


あと、このときに Lazy Load という、これもまたJavaScriptのライブラリを導入した。

一気にサムネイルを読み込むのが悪いんだろうと思って導入したのだが、

数百個が数十個に減っても、MaxConnPerIPの規制値にかかってしまうので、結局、効果はなかったんだが。

とはいえ、画面の外にある画像のロードは後回しにして、ページ表示が完了するので、それ自体は好ましいことではある。

こういうのが簡易に導入できるんだから便利な話ですよ。


Author : Hidemaro
Date : 2019/12/16(Mon) 23:52
コンピュータ・インターネット | Comment | trackback (0)

Tools