2018年02月07日

Hacknetの全画面表示でFPSがおかしくなるときの解消方法

Hacknetという、とても面白いゲームがある。
1000円程度と安いが、とても本格的で面白い。音楽も良いゲームだ。
http://store.steampowered.com/app/365450/Hacknet/?l=japanese

ハッキングシミュレータであり、キーボード叩きゲーである。
UNIX風のコマンドを叩き、映画のホワイトハッカーにでもなったかのような楽しい体験ができる作品だ。
一見おかしな設定も、ゲーム内のテキストファイルをあさってゆくと色々と説明が出てくる。
PCに詳しい人はなりきり体験とあるあるネタとして、
PCに詳しくない人は、PCに興味を持つきっかけや、コマンド操作のチュートリアルとして
どちらもおすすめである。

ところでこのゲーム、なぜか全画面表示でやるとFPSがおかしくなる。
普通はならないらしいが、自分のPCでは10〜999FPSを超絶行き来しており、
その上実際は10FPSくらいが不安定に出る感じで、うまく動かない。

ウィンドウモードでは60FPSで動くのだが、全画面にするととたんにダメになる。
ウィンドウモードでプレイしたが、没入感に欠ける。

で、この度PCをSSDにしたついでに解決策を探してみた。
結果、ビデオカードの「垂直同期」を「アプリケーション依存」から「強制オン」に切り替えたところ、
60FPSで安定して動くようになった。FPS自動調節機能でも誤動作していたのだろうか?

ともかく、これで没入感たっぷりで遊べるようになった。
posted by gpsnmeajp at 00:05| Comment(0) | TrackBack(0) | トラブル解決

2018年02月03日

Felica Liteの中身をダンプしたりNDEFタグ化したりするツール作った

EasyPCSCFelicaLiteConsoleを作りました.
タイトルの通り,Felica Liteの中身をダンプしたりNDEFタグ化したりするツールです.
いろいろ入れたりする必要なく,EXEファイル1つとPaSoRiの標準PC/SCドライバで動く軽量ツールです.
https://sabowl.sakura.ne.jp/gpsnmeajp/cpp/easypcscfelicaliteconsole/

shot1.png

ここ数日開発していたライブラリのLazyPCSCFelicaliteは,これを作るため以前作成したプログラムをライブラリ化していたら火がついてしまって作り込んでしまったものです.

こちらはこちらで,MACを使用した片側認証・相互認証に対応した力作です.
ライセンスも緩めですので,どうぞご利用ください.
https://sabowl.sakura.ne.jp/gpsnmeajp/cpp/lazypcscfelicalite/
posted by gpsnmeajp at 23:28| Comment(0) | TrackBack(0) | プログラム

2017年12月04日

Intel rapid storage technologyを削除したらHDDの平均応答時間が早くなった?

最近PCがやたら重い。

HDDの平均応答時間が500msとかおかしな値になっていたので、
ぐぐってみると、Intel rapid storage technologyが導入されていないと起きるとのこと。
しかし、導入されている。謎である。

試しにIntel rapid storage technology削除してみたが、変化が起きない。
そこでさらに、SATAコントローラのドライバを削除してみた。

見事にWindowsが起動しなくなったが、セーフモードで起動後、再起動すると問題なく起動した。
ドライバがかなり古いものにフォールバックしたが、その結果、平均応答時間が3〜50ms程度と大きく改善した。
何だったのだろう。
posted by gpsnmeajp at 00:09| Comment(0) | TrackBack(0) | トラブル解決

2017年11月29日

YubikeyのU2F認証の仕組み(登録件数が無限なしくみ)

Yubikeyは、セキュアエレメント搭載のセキュリティーキーですが、
そういえばFIDOのU2Fには何件対応しているのだろう、と思いました。

FIDOのU2Fは、認証デバイスが鍵ペアを生成して保管し、
それを認証デバイス側と、サイト側で相互に突き合わせて強固な認証を行います。

Yubikey内のストレージは有限かつ少量で、それは各機能の登録データ数の制限等を見ると明らかです。
しかしながら、U2F認証を要求するサイトは数十、数百と増えるでしょう。
そうした時に、上限に達したらどうなるのか?

これ以上登録できませんとなるのか?削除の仕組みがある?それともまさか古い順に削除される?
調べてみると、公式サイトに回答がありました。

how many services can the u2f-certified YubiKeys be associated with?
https://www.yubico.com/support/knowledge-base/categories/articles/many-services-can-u2f-certified-yubikeys-associated/

「利用できるサービスの数の制限はありません。
 鍵ペアは生成されますが、デバイスには保存されず、登録サービスに保存されます。
 そのため実質的に無限に登録できます。」

最初これを見たとき、「え?」となりました。
・鍵ペアをサービスに保存したら意味なくない?
・Yubikeyからどうやって認証してるんだ?
・そもそもFIDOの仕様に、サイト側に保存する仕組みなんてあったっけ?

開発者向けサイトに答えがありました。
なかなかおもしろい仕組みを使って実装されています。

Key generation - Yubico Developers
https://developers.yubico.com/U2F/Protocol_details/Key_generation.html

ただしこれも理解に時間がかかったので、自分の理解の結果を以下に示します。
誤りが含まれているかもしれません。上記のURLの内容そのままといえばそのままですので、ご確認ください。

前提
・キーデバイスは、AppID(ドメイン名含む)でサイトを識別する。(これがフィッシング対策になる)
・同じサイトで、違うアカウントの認証情報が必要な場合があり、AppIDでは識別できない。
 そのために鍵の識別はKeyHandleを用いて行う。このKeyHandleは、デバイスが生成してサイトに送る。
・しかし、そうしたところで、セキュアなストレージが大量に必要になる。
 FIDOは鍵の格納方法を指定していないため、Yubikeyでは違ったアプローチをしている。

登録フェーズ
1. Webサービスは、AppID、Challenge(リプレイ攻撃対策乱数)とともに登録リクエストをする
2. Yubikey内で、乱数からNonceを生成する。
3. Yubikey内で、AppIDとNonceをデバイス内部鍵(固定)で署名ハッシュを取り、
 これを秘密鍵とする。
4. Yubikey内で、秘密鍵から公開鍵を生成する。
5. Yubikey内で、AppIDと秘密鍵、デバイス内部鍵(固定)で署名ハッシュを取り、
 秘密鍵ハッシュ(MAC)を生成する。
6. Yubikey内で、NonceとMACの一部を結合し、KeyHandleとする。
7. Yubikey内で、公開鍵・KeyHandle・Challenge・AppIDを秘密鍵で署名し、サービスに返す。
8. 内部カウンタを加算する。

認証フェーズ
1. Webサービスは、AppIDとKeyHandle、Challenge(リプレイ攻撃対策乱数)を渡して認証要求する
2. Yubikey内で、KeyHandleから登録時のNonceと秘密鍵MACを取り出す
3. Yubikey内で、AppIDとNonceをデバイス内部鍵(固定)で署名ハッシュを取り、これを秘密鍵とする。
4. Yubikey内で、秘密鍵から公開鍵を生成する。
5. Yubikey内で、AppIDと秘密鍵、デバイス内部鍵(固定)で署名ハッシュを取り、
 秘密鍵MACを生成する。これを、KeyHandleから取り出したMACと比較し、正しいか検証する。
 (正しくなければ、これはこのYubikeyのものではないか、あるいは改変されている)
6. Yubikey内で、KeyHandle・Challenge・AppIDを署名し、サービスに返す。
7. 内部カウンタを加算する。

結論として、Yubikey内には、秘密鍵も公開鍵もKeyHandleも保存されない。
デバイス内部鍵は、Yubikeyに出荷時に書き込まれているものであり、取り出しも変更もできない。
内部的に変化するのはカウンタだけである。

秘密鍵は、NonceとAppIDと、デバイス内鍵の3つから「毎回」生成されている。
Nonceは、登録時は乱数だが、認証時は登録時に渡したKeyHandleがサービスから帰ってくる。
KeyHandleは、Nonceと秘密鍵MACを結合したものであり、そのためこれで秘密鍵生成データが揃うことになる。

このままだと、全く登録していないサービスなどから要求されても、
無効な署名を渡してしまうが、それはKeyHandleに含まれている秘密鍵MACを使うことで
KeyHandleが自分が生成したものかをチェックできる仕組みになっている。

よくできている。
posted by gpsnmeajp at 14:08| Comment(0) | TrackBack(0) | 日記

2017年11月27日

Yubikeyが届きました&雑感

Yubikeyが届きました。
不安になるくらいシンプルな梱包と定評がありましたが、本当にその通りでした。
A0.jpg

ネックストラップを付けてこんな感じ。
A2.jpg

実際使ってみての感想ですが、
・タッチの仕方
Slot1はチョイ押し、Slot2は押しっぱなしでちょうどいい
ボタンじゃなくて静電タッチだから押した感覚なくてちょっと困惑する
(ホームボタンのように馬鹿になりにくいので安心感はある。)

・Static Password
試しに使ってみたが、長いユーザー名と長いパスワードを全部入れるには
ちょっと足りない。TabとEnter含めて38文字までというのは微妙にきつい。
(パスワードのみなら何の問題もなかった)
※公式的には、パスワードまるごと入れるのはおすすめされていません。
 あくまで試しにやってみた形です。

セキュリティ意識低い人たちに対してなら、ありかもしれない

あと文字数制限オーバーの際、書き込み失敗メッセージが
「ロックされてるかも」なのは心臓に悪いので止めて欲しい。

・ネックストラップ
首から下げるのは、無くしにくいが、使いにくい。
NFCならともかく、USBだとね...
いい方法無いだろうか?

今回買ったもの

[正規販売代理店品]YubiKey 4 Yubico
https://www.amazon.co.jp/dp/B018Y1Q71M/ref=cm_sw_r_tw_dp_x_OJahAbH30RB3K

HAKUBA ネックストラップ PixGEAR コネクトストラップ ブラック コンパクト用 ライン/ボーダー ブラック KST-49BK ハクバ
普通よくある、アクセサリー部の取り外し部分がないので、耐久性が高そうである。
また、ストラップ自体に2箇所ある取り外し部を付け替えると、ハンドストラップにもなる。
https://www.amazon.co.jp/dp/B008JIAOU6/ref=cm_sw_r_tw_dp_x_ULahAb6YYS7HQ
posted by gpsnmeajp at 21:50| Comment(0) | TrackBack(0) | 日記

URLを含んだ文にリンクを自動で貼る変換器

URLを含んだ文にリンクを自動で貼る変換器を作りました。

URLを含んだ文にリンクを自動で貼る変換器
https://sabowl.sakura.ne.jp/gpsnmeajp/tool/tolink.htm

↑例えばこういう文を、↓のようになるようにAタグを付加します。

URLを含んだ文にリンクを自動で貼る変換器
https://sabowl.sakura.ne.jp/gpsnmeajp/tool/tolink.htm

完全俺得ツールですが、必要になるときってありません?
例えば、勝手にリンク張ってくれる系のサイトから、張ってくれない系のサイトに移動するときとか。
posted by gpsnmeajp at 00:02| Comment(0) | TrackBack(0) | 雑感

2017年11月26日

Yubikeyをオフラインで使う方法を考えてみる

さて、先の記事では長々と公式サイトを見ればわかるようなことを書いてしまいましたが、
Yubikeyのオフラインでの認証の利用方法を考えてみます。

一見、Yubikeyはオンラインでの利用が前提なように見えます。
実際、オンラインで利用する場合は、予め適当な認証情報が
出荷時に書き込まれているため、設定ツール無しで利用できます。
YubiCloudを使えば、無料で強固な認証システムも利用できます。

しかしながら、自PCやプログラムで使いたいといった場合、
オンライン接続必須な状況は嫌われます。その場合どうするか。

簡単なのから順に、難しいものまで考えてみました。

ちなみにですが、OTP(Static Password含む)とU2FとCCID(PIV等)は、
独立した機能であり、それぞれ有効無効が切り替えられます。確か。


※オンラインで利用できる場合、YubiCloudを使うのが一番簡単で安全です。
 出荷時に鍵が書き込まれており、利用者ですら鍵情報を知らないため。

※この文は暗号化や認証に関して全くの素人な人が書いています。
 業務等に使う場合は、専門家の意見を参照してください。


・Static Password
おすすめ度:★★★☆☆
導入容易度:★★★★★
評価: 運用方法に気をつければアリ。公式が想定した使用法の一つ。

まず、一番簡単なのはStatic Passwordですね。
Yubikeyはキーボードとして認識され、タッチすれば入力されます。
それだけだと1要素認証になるので、パスワードの先頭数文字は
手入力するようにすれば擬似的な2要素認証として使えます。

例: 5523vgdksjisnkldscmlskbcjsnckaslmkisd
  ↑手入力 ↑yubikeyに保存したパス

任意のキー入力最大38文字の他、秘密鍵で生成されたmodhex最大64文字を使うことも可能。
人間のパスワード入力の代替であれば前者、yubikey前提なら後者が安全でしょう。

キー入力を覚えさせることができるので、ユーザー名→Tab→パスワード→Enter(合計38文字以内)とすることもできます。
完全な「鍵」としての利用ならこちらも便利。

使用例
・公式で提示された使用法
・BIOSパスワード(Yubicoフォーラム)
・TrueCryptのブート時認証(Yubicoフォーラム)

利点
・プログラムや機器での特別な対応が不要。
・既存のパスワードを使うなら機器側の設定は一切不要。(yubikeyの設定は必要)
・お手軽にセキュリティ強化ができる上に、引き継ぎも楽
・嫌われがちな長いパスフレーズを覚えること無く普及させられる

欠点
・メモ帳を対象に実行すればパスワードが平文で漏出する
・鍵の複製が容易どころか、コピペですら良い
・キーロガーには全くの無力
・初期設定が必要
・もちろんリプレイ攻撃には無力
・フィッシングにも無力
・yubikeyと、手入力や他の機器との区別は不可能

結論
 信頼できる機器だけを対象として使うのであれば有効でしょう。
 ITに不慣れで、パスワードを紙に書いて管理してしまうような
 現場であればなおのこと有効性は高いです。


・Yubico OTPの固定IDの利用
おすすめ度:★★☆☆☆
導入容易度:★★★★☆
評価: あまりおすすめしない

Static Passwordは設定が必要です。
用途にも寄りますが、無設定で運用したいという場合もあるでしょう。
自ツールから鍵の書き込みもできるはずですが、それも面倒と。

Yubico OTPで生成されるワンタイムパスワードは、
全てがランダムな文字列になっているわけではありません。
(特に設定を変えていなければ、ですが)

先頭にpublic idが12文字付き、その後が暗号32文字からなります。
このpublic idは、設定を変えない限り変化せず、後半の暗号を解くための鍵を
サーバー上で探すための、いわば鍵IDの役目をしています。

つまり、先頭12文字だけを切り出して使えば、
差し込まれているyubikeyの個体識別ができるわけです。

使用例
・パスワード管理ソフトのLastPassのオフラインアクセス設定

利点
・先頭12文字を切り出して比較するだけのお手軽実装
・yubikeyは購入したての無設定でよい。(アプリ側に登録する作業は必要)
・一見ランダムな文字列に見えるので、難しそうに見える

欠点
・仕組みがバレれば簡単に漏出する
・鍵の複製が非常に容易。どころか、コピペですら良い
・キーロガーには全くの無力
・もちろんリプレイ攻撃には無力
・フィッシングにも無力
・一見強固に見えるがゆえにむしろ危ない
・yubikeyと、手入力や他の機器との区別は不可能
・独自アプリケーションの開発が必要
・英字小文字12文字(しかも各文字は16種類しかない)ってあまり強くない気がする
 ※通常のパスワードと同様に解析されたとすると、カスペルスキーいわく
  家庭用PCで2世紀、ボットネットで2日、スパコンで16分でアタック完了するとのこと。

結論
 信頼できる機器だけを対象として使うのであれば有効...?
 これ使うくらいならstatic passwordの方がまだ安全なのでは...?
 とりあえずこれでログインして、その後のサービスの利用には
 YubiCloudを使う、とかなら、UXが統一されていて便利...?


・Yubico OTPをオフラインで使う
おすすめ度:★☆☆☆☆
導入容易度:★☆☆☆☆
評価: 全くおすすめしない

Yubico OTPで生成されるワンタイムパスワードは、
public ID、private ID、暗号鍵、内部カウンタの主に4つ(+α)で構成されています。

認証の際は、yubikeyから入力されたデータを元に、
public IDから、暗号鍵, private ID, 前回のカウンタ値をデータベースから取り出します。

そして、暗号文をAES128で復号、出てきたprivate IDが一致するか、
カウンタ値が増えているか、を確認します。

これにより、本物かのチェックと、リプライ攻撃ではないかのチェックをしています。
public ID、private ID、暗号鍵は、設定ツールから設定が可能です。
(取得はできません。あくまで新規設定です)

ので、これらの情報が揃っていれば、オフラインでもYubiCloudと同等の検証が可能です。
これらの仕様は公式に公開されています。

使用例
・おそらくなし

利点
・実装は手間だが、きちんとしたワンタイムパスワードとして動作するため検証は強固
・リプライ攻撃に強い。
・キーロガーの影響もなし。
・コピペはリプライ攻撃として弾かれるのでOK
・鍵の複製は利用者からは難しい
・手打ちは実質不可能

欠点
・フィッシングに対してはさほど強くない(次に認証されるまでは有効なため)
・オフラインでの利用の場合、PC内にAES鍵等が保存されており、
 それを抽出された場合、オンラインでの認証(YubiCloud含む)にまで
 利用できるほぼ完全な複製鍵が作れてしまう
・yubikeyの設定が必要
・独自アプリケーションの開発が必要

結論
 セキュリティが保証された専用機器で使うならともかく、
 PCなどで使うにはおすすめできない。
 ほぼ完全な複製鍵が作れてしまうのが致命的な欠点。


・Challenge ResponseのHMAC-SHA1を普通に使う(共通鍵)
おすすめ度:★★★☆☆
導入容易度:★★★☆☆
評価: 用途次第

yubikeyのChallenge Responseモードを使うと、
アプリケーションがChallengeを送信し、yubikeyからResponseを受け取ることができる。

応答は、あらかじめyubikeyに書き込んでおいた共通鍵と、
アプリケーションが渡すChallengeから生成されるハッシュとなっている。
それにしか起因しないので、Challengeが同じであれば、同じ結果が帰り続けるし、
共通鍵を揃えておけば違う個体でも同じ結果が帰る。

使い方としては、アプリケーションとyubikeyに予め同じ共通鍵を記録させておき、
認証が必要になったら、適当な乱数をyubikeyに送る。
帰ってきたら、自分の手元で計算した結果と同じかどうかをアプリケーションが検証。
同じならOKと言った形。

公式いわく「無人モード」「ドングルモード」と呼ばれていて、
実際、今までの方法とは違い、ユーザーがyubikeyをタッチする必要はない。
(タッチする必要があるように設定を変えることもできる。)

また、継続的に監視でき、突如別のyubikeyに差し替えられても検出できる。
(シリアルナンバーでも監視できるが、シリアルナンバーは不可視にできるので不確実)

使用例
C#でYubikeyのChallenge Response認証を行なうプログラム

利点
・実装は手間だが、きちんとしたワンタイムパスワードとして動作するため検証は強固
・リプライ攻撃に強い。
・キー入力ではないのでキーロガーの影響もなし。
・同じくコピペも手打ちも原理上不可能
・鍵の複製は利用者からは難しい
・フィッシングも無効
・Yubico OTPの鍵とは独立しているので、秘密鍵が漏出しても影響範囲が小さい

欠点
・オフラインでの利用の場合、PC内に共通鍵等が保存されており、
 それを抽出された場合複製鍵が作れてしまう
・yubikeyの設定が必要
・独自アプリケーションの開発が必要

結論
 信頼できる機器だけを対象として使うのであれば有効でしょう。
 秘密鍵の管理が重要になります。これが漏れると大変なことに。
 常にさして置かなければいけない、といったポリシーを適用するならその方向には有効。
 Static Passwordの次くらいにおすすめできる程度


・Challenge ResponseのHMAC-SHA1の次レスポンスを記憶しておく
おすすめ度:★★★★★
導入容易度:★★★☆☆
評価: 十分にあり。公式サンプルにある。

Yubico公式のWindowsログオンサンプルは少々面白い方法を使用しています。
Challenge Responseモードの「Challengeが同じであれば、同じ結果が帰り続ける」という
特性を活かし、以下のような手順で認証しています。

登録
1. まず、Yubikeyに適当なChallenge(0)を投げる
2. Yubikeyから帰ってきたResponse(0)と、Challenge(0)を記録しておく。
 これで登録完了。

認証(初回はn=0)
1. 前回使用した、Response(n)のわかっているChallenge(n)をYubikeyに投げる。
2. Yubikeyから帰ってきたResponse(n)と、手持ちのResponse(n)を比較する。
3. 一致していたら認証は完了だが、次回に向けた再登録処理を続ける。
4. 次回の認証のために、Yubikeyに新たに別の適当なChallenge(n+1)を投げる
5. Yubikeyから帰ってきたResponse(n+1)と、Challenge(n+1)を記録しておく。
6. 次回は(n+1)を使って認証する。

どうですか?このシンプルな仕組み。
認証する側はHMAC-SHA1を処理する必要すらありません。

オンラインではスニッフィングされると無意味ですが、オフラインのUSB経路で
そうなる可能性が非常に低いとするならば、非常に頭の良い実装だと思います。
Yubikeyに触れないで処理が進む、「ドングルモード」ならではの実装でもあります。

使用例
公式のサンプル解説

利点
・実装が容易な上、きちんとしたワンタイムパスワードとして動作するため検証は強固
・リプライ攻撃に強い。(USBパケットが抜かれていない限り)
・キー入力ではないのでキーロガーの影響もなし。
・同じくコピペも手打ちも原理上不可能
・鍵の複製は利用者からは難しい
・フィッシングも無効
・Yubico OTPの鍵とは独立しているので、秘密鍵が漏出しても影響範囲が小さい
・共通鍵をPC側に持たないため、漏出の心配がない
・ハッシュが漏出したとして鍵を求めるのは非常に困難

欠点
・yubikeyの設定が必要
・独自アプリケーションの開発が必要
・何らかのエラーでResponseとChallengeが破損するとロックアウトされる
 (認証の度書き換わるため)

結論
 オフライン認証は多分これが一番バランス取れていると思います。


・FIDO U2Fを使う
おすすめ度:?????
導入容易度:?????
評価: 未評価

筆者が理解できていないため、残念ながらろくに書けないのですが、
一応調べた情報だけ書いておきます。

FIDO U2Fも結局のところ、一種のChallenge-Responseです。
登録時は、Challengeを送ると、Yubikey内に秘密鍵・公開鍵ペアが生成されます。
そして、秘密鍵により署名された公開鍵と鍵ID、Challengeが帰ります。

認証時はChallengeと鍵IDを送ると、Yubikeyから秘密鍵により
署名されたChallengeと鍵IDが帰ります。

認証する側は、公開鍵と鍵IDを持ち、Yubikeyは秘密鍵を持ちます。
※実際にはどうやら、Yubikeyは秘密鍵を持たず毎度生成しているようです。

オンラインでも利用できる以上、オフラインでも利用できるはずです。
(実際、sudo時にU2Fを要求する実装があるようです)

Challenge Responseモードと比較すると、公開鍵による検証が可能なことと、
Yubikeyの設定が不要なこと、安価(2000円くらい安い)なFIDO専用キーが利用できる利点があります。
さらに、原理的に実質無限のサービスを登録できます。

欠点は... どうやって実装しているんだろうなぁ、って思うくらいですかね...
個人的に導入が難しそうだと思います。(出来合いのものを使うならともかく
)

U2FHIDの仕様に従って実装すればできそうです。
Python向けライブラリもあるようですので。

使用例
・LinuxのPAM

・PIV・PGP スマートカード認証
おすすめ度:?????
導入容易度:?????
評価: 未評価

これも筆者が理解できていないため、残念ながらろくに書けないのですが、
一応調べた情報だけ書いておきます。

今まで、Yubikey自体は何の保護もない、差し込まれれば認証情報を渡すタイプの
認証方式を紹介してきましたが、PIVは違います。

Yubikeyには、スマートカードとして、デバイス内部で4個(Yubikey4だと24個!)までの
秘密鍵を生成・保持する機能があります。
また、既存の秘密鍵を入れることもできます。

この秘密鍵は、PIN(暗証番号)で保護され、3回間違えると鍵情報がロックされます。
その状態で、管理者PUKを3回間違えると永久にロックされる。

USB通信の経路上も暗号化されて通信するようです。

SSHの認証や、Windowsのログオン、リモートデスクトップの認証、PGPなど、
かなり色々使えるようです。
自分のソフトウェアで認証に使うのももちろんできるでしょう、多分。

自己署名についてのいろいろがよくわからない...
公開鍵を用意し?秘密鍵を使って証明書署名要求を生成(署名)し?
秘密鍵を使って証明書署名要求にさらに署名して、証明書を生成する?

使用例
・LinuxのPAM
・その他色々


参考文献
ワンタイムパスワードトークンYubiKey |(株)ソフト技研
https://yubikey.yubion.com/yubikey_lineup.html

Yubico Forum • View topic - Challenge-response mode - FAQ :
https://forum.yubico.com/viewtopic.php?f=4&t=632

二要素認証に使われてるYubico OTP の仕組み - 試運転ブログ :
http://otameshi61.hatenablog.com/entry/2016/12/30/211358

Windows Helloに対応したセキュリティ認証デバイス「Yubikey」の使い勝手を試してみた – Dream Seed :
https://www.dream-seed.com/weblog/review/yubikey

spp5: C#でYubikeyのChallenge Response認証を行なうプログラム :
http://spp5.blogspot.jp/2013/03/cyubikeychallenge-response.html

秘密鍵、管理してますか? YubiKeyで鍵の一元管理とSSH接続、2段階認証の高速化を試す - Qiita :
https://qiita.com/dseg/items/77d77467970b1b510285

My Work Day Reflects YubiKey's Flexibility | Yubico :
https://www.yubico.com/2015/03/employees-day-showcases-yubikeys-flexibility/

spp5: YubiCloud認証プログラムを作る :
http://spp5.blogspot.jp/2012/06/yubicloud.html

YubiKeyManual_v3.4.pdf :
https://www.yubico.com/wp-content/uploads/2015/03/YubiKeyManual_v3.4.pdf

YubiKey - もわの書斎 :
https://mowa-net.jp/wiki/YubiKey#Yubico_OTP.2BMG5O1WnY-

Yubikey 4 にSSHの秘密鍵を格納する – n10の個人的なメモ :
http://mirahouse.jp/n10/2017/08/29-121537.html

yubikeyでセキュリティ筋力を鍛える ・ JoeMPhilips : http://joemphilips.com/post/yubikey_setup/

YubiKeyのPIVカードでSSHする - cuspy diary :
http://www.cuspy.org/diary/2015-08-11-yubikey-piv-ssh/

YubikeyのPIVを使ってsshしてみる - 試運転ブログ :
http://otameshi61.hatenablog.com/entry/2017/05/21/144208

家にssh鍵を忘れるという概念 - hiroqnの日記 :
http://hiroqn.hatenablog.com/entry/2017/09/02/213519

RSA鍵、証明書のファイルフォーマットについて - Qiita :
https://qiita.com/kunichiko/items/12cbccaadcbf41c72735
posted by gpsnmeajp at 23:58| Comment(0) | TrackBack(0) | 雑感

ブログデザインの調整

次の記事を参照、と言って申し訳ないですがこの記事ではないです。
ブログのフォントや大きさが、なんというか昔ながらと言うか、すごく見づらい小ささだったので、
見やすい大きさとフォントに変更しました。

CSSの!important;指定とか初めて使いました
posted by gpsnmeajp at 20:06| Comment(0) | TrackBack(0) | 日記

USB認証鍵Yubikeyの機能

Yubikeyに最近興味を持ちました。
Googleの二段階認証などで使えるハードウェアトークンですが、
スタイリッシュな上、思っていたより機能があります。

ただ、生まれて8年近く立つ商品ですが、セキュリティ専用商品なためか、
日本ではあまり流行っていないようなので、ざっと機能のまとめと、
個人的に気になったオフラインでの利用に関して、調べた結果をまとめてみます。

※購入済みですが、まだ運用していません。公式サイトを見ればわかるようなことのメモです

Yubikeyの機能


Yubikeyには、比較的高価なYubikey4(5000円程度)と、
一番高価なYubikeyNEO(6000円程度)、安価なYubico U2Fセキュリティキー(3000円程度)があります。

それぞれで値段が違うのは、当然使える機能が違うためですが、
NEOが最上位機種かというとそうでもないので注意してください。
ちなみに、超小型版のnano、USB-C用のCもありますが、それらは基本スティック型のと同じです。

機能を以下にまとめます。
・Secure Element
 海底48mに沈めて二ヶ月放置しても、洗濯乾燥機に突っ込んでも壊れない堅牢性と
 分解・解析に対する耐タンパ性を持ちます。
 Yubikeyにデータを書き込むことは簡単にできますが、読み出すことは一切できません。
 そのため、鍵情報などが漏れることはありません。

 不揮発性のカウンタを内蔵しており、同じOTPは生成されません。
 ただし、1日10回使用したとして18年使えるカウント回数があります。

 生体認証等の機能はついていません。これはあくまでYubikeyは
 2要素認証の2要素目として使われる前提のためです。
 自宅の鍵と同じく肌身離さず持ちましょう。
 一方、その性質から、引き継ぎの際には鍵のように渡すだけで済みます。

 ※スマートカードなどにはもちろんPIN保護を掛けられます。

・Yubico OTP*
 Yubico独自のAES暗号を用いたワンタイムパスワード生成です。
 キーボード配列に影響されない英字入力機能を使い、キー入力として動作。
 ブラウザやシステムを選ばず、iPadやスマートフォンでさえ動作します。
 社内システムなどで簡単かつ堅牢なOTPシステムを導入できます。
 無料のOTP検証クラウドサービスYubiCloudがある他、
 自前で検証サーバーを立てることもできます。
 ※U2Fセキュリティキーには搭載されていません

・OATH-HOTP*
 一般的なカウンタ+シークレット方式のワンタイムパスワードを生成します。
 生成はYubikey内で行われるため安全に生成できます。
 ※U2Fセキュリティキーには搭載されていません

・OATH-TOTP*
 一般的な時刻情報方式のワンタイムパスワードを生成します。
 ただし、時計機能を内蔵していないため、時刻情報は外部から取得します。
 生成はYubikey内で行われるため安全に生成できます。
 ※U2Fセキュリティキーには搭載されていません

・FIDO U2F
 Googleなどの二段階認証サービスで利用される規格です。
 公開鍵方式を利用したオンラインでの強固な二段階認証です。
 HIDで通信するためドライバは不要ですが、対応ブラウザが必要です。

・Challenge Response*
 公式的に「ドングルモード」や「無人モード」と呼ばれます。
 オフラインのソフトウェアとの認証に使うことができ、
 Yubikeyが継続的に刺さっているか、あるいは、正しいYubikeyが刺さっているかを
 Yubico OTPか、HMAC-SHA1のチャレンジ&レスポンスで検証することができます。
 
 Yubico OTPは同じチャレンジでも内部カウンタ等により違うレスポンスを返しますが、
 HMAC-SHA1は同じチャレンジの度に同じレスポンスを返します。
 ※U2Fセキュリティキーには搭載されていません

・Static Password*
 静的パスワードモードです。
 BIOSパスワードなどの、OTP等に一切対応していない機器でも、
 長いパスワードをyubikeyに入れておき、先頭数文字を手動で入力後、
 続きをyubikeyに打たせることでセキュリティを強化できます。
 セキュリティは低下しますが、38文字までの全パスワードあるいは、
 ユーザー名とパスワードを入れておくことも可能です。
 (Tabキーや改行、キーコードを入れることができます)
 
 ※U2Fセキュリティキーには搭載されていません

・Smart Card(PIV-Compatible)*
 単体でスマートカードとして動作させることができます。
 そのため、SSHの公開鍵認証や、WindowsPCの認証に使用することができます。
 ※U2Fセキュリティキーには搭載されていません

・OpenPGP*
 PGPの秘密鍵をYubikeyに入れておくことができます。
 メールの署名や、ソースコードの署名に利用できます。
 ※U2Fセキュリティキーには搭載されていません

・NFC通信**
 YubikeyNEOにはNFC機能が内蔵されており、単なるMifareタグとしてのID検証から、
 スマートフォンでのワンタイムパスワードの生成、NFC経由でのOTP等利用できます。
 Yubikey社のオフィスドアはNFC-OTPでロックされているようで、
 単なるRFID検証に比べると非常に安全です。
 ※YubikeyNEOにのみ搭載されています。

・NDEF**
 YubikeyNEOには好みのNDEFタグ情報を書き込み利用することができます。
 ※YubikeyNEOにのみ搭載されています。

・FIPS 140 Certification***
 米国連邦標準規格により、安全性が確認されています。
 ※Yubikey4シリーズのみ。

・オープンソース性(ハードウェアとファームウェアを除く)
 YubikeyNEOは開発者向けの商品であり、オープンソースでした。
 Yubikey4はクローズドソースに移行しており、NEOもクローズ方向に使用が変更されています。
 Yubico社いわく、高セキュリティのためのICの開発環境とオープンソースは相性が悪く、
 オープンソースの恩恵が得られないどころか、負の効果が有るためとしています。

 PC側の設定ツールや、認証サーバー、通信仕様などはオープンに公開されています。

・ファームアップデート機能非搭載
 YubikeyはBadUSB問題等を考慮し、ファームウェアアップデート機能を
 搭載していません。
 そのため、新しい機能が追加された場合、たとえ同じシリーズでも
 新規購入する必要があります。

・マスストレージ機能非搭載
 Yubikeyにはマスストレージ機能(USBメモリ機能)は搭載されていません。
 ウィルス等の感染経路となるためです。

暗号仕様


・RSA 2048
 Yubikey4、NEO両対応

・RSA 4096***
 Yubikey4のみ

・ECC p256**
 全機種対応

・ECC p384***
 Yubikey4のみ

参考文献


次の記事を参照してください。
posted by gpsnmeajp at 19:53| Comment(0) | TrackBack(0) | 雑感

2017年11月22日

BLE (Bluetooth LE)に関するメモ

BLE (Bluetooth LE)に関して、自分が疑問に思ったこと、突っかかったことのメモ。
誤りが大量に含まれている恐れがあります。

・BLEは基本的にGATTの操作が主となる。
[物理層]→[L2CAP]→[ATT]→[GATT] GATT(読み書き)はこのように積み重なっている
[物理層]→[L2CAP]→[SMP]→[GAP] GAP(アドバタイジング・接続処理)はこのようになっている。
 ※上記から、アドバタイズメントとGATTは別物。

・GATTは、名前付き変数の操作・取得をするための構造と考えるとわかりやすい。
・そのシンプル化された仕様の結果、汎用性と相互接続性が高い。

・GATTはリモコン的な状態の変更・取得が主であり、ストリーム的通信には至極向いていない。
 デバッグも難しくなる(単なる変更・取得ならば多くのBLE探査ソフトウェアが使用できるが、
  ストリームの場合は専用アプリを作らざるをえない。)
 ※UARTとか、MIDIとかあるけどね...

・ストリーム的通信をしたければL2CAPを直接使うようだ。(よくわからない)


・パケットペイロードサイズは27Byte。
・転送可能なデータサイズ(MTU)は23Byte。(これはMTU交換により最大251バイトまで大きくなる)
・一般的に用いられるキャラクタリスティックのサイズは20Byte程度。Read Characteristicで読める。
・キャラクタリスティックの最大サイズは512Byte。
 Read Long Characteristic(Read Blob Request)で2バイトのオフセットを指定して複数回読み出すことで読み出せる。
 
・複数のキャラクタリスティックを一括で読み出すこともできる。
・長いキャラクタリスティックをキューイングして書き込むこともできる

・アドバタイジングのデータサイズは31byte。(パケットサイズは37Byte)
 スキャン応答時も同じサイズの、中身の違うデータを返すことができる。

・ボンディングとペアリングがあるが、Bondingが多分思ってるやつ。
 暗号化するのが普通だが暗号化しないこともできる。
・通常、MACアドレスはランダム化されていて、再接続や追跡は困難だが、
 Bondingされている相手ならMACアドレスを復元して再接続可能

・BLEデバイスは、基本通信やBondingが成立すると無向アドバタイジングを止める。
 接続情報のリセットが行われるまでこの状態なことが多い。省電力性と隠匿性のため。
 特定の機器と即座に接続したい場合は、有向アドバタイジングを行う。
 ただスマホ向けの機器の場合や、接続待ちの場合は延々と無向アドバタイジングし続ける事が多い。用途による。

・変数に当たるのがCharacteristic
・Characteristicを束ねたものがService
・用途別に同名のCharacteristicが存在しうるがServiceで区別できる
・CharacteristicもServiceも、UUIDあるいはHandleで区別する。
・UUIDは変化しない固有のもの、Handleは電源再投入などで変化しうる
・UUIDは長くデータ効率が悪いが確実、Handleは短く効率が良いが不確実
 ※もっとも、スマートホン等では接続時にServiceやCharacteristicの検索を行い、
  内部的にUUIDからHandleに変換するので気にすることはない。
  →キャッシュに注意。Peripheralから更新通知ができる。

・GATTの接続・切断と、物理的な電波の接続・切断は別?

・Peripheralから能動的に送信するにはNotificationを使用する。
・Indicationは確認付きのNotificationである。

・通信路の暗号化をしたければBonding
・正規品認証をしたい場合は、Challenge & Response

参考文献
BLEの通信仕様 | Reinforce-Lab.'s Blog

[CB16] スマートフォン制御のIoTデバイスにおけるBLE認証設計の課題:Gogoroスマートスクターの分析を通じて by Chen-yu Dai [GD] & Professor Shi-Cho Cha [CSC]
posted by gpsnmeajp at 21:41| Comment(0) | TrackBack(0) | プログラム

2017年11月13日

Pythonistaの準備用スクリプトのメモ

iOSのPython開発環境Pythonistaで、
シェルっぽい環境のStaShと
サンプルやツールなどのダウンロードツールptinstaller.pyの導入をするスクリプト


import requests as r;
o=open('ptinstaller.py','w');
o.write(r.get('https://raw.githubusercontent.com/ywangd/pythonista-tools-installer/master/ptinstaller.py').text);
o.close();
exec(r.get('http://bit.ly/get-stash').text);
posted by gpsnmeajp at 20:39| Comment(0) | TrackBack(0) | 雑感

2017年10月26日

LazyBLEWrapper v0.13公開(処理の変更と整理)

・メモリリーク防止の観点からコンテキストを保持しないように変更。
・final
・connectで必ずdisconnectするように変更。
・BLE関係のメソッドをUIThreadで実行するように設定。
・メソッドの並び替え(ドキュメントをJavaらしい書き方にすべきかも)。
・disconnectを丁寧にするように。(Threadでの実行が必須に)。
・GATTのnullチェックを強化。
・forceDisconnectを追加

Android特有の色々癖があるようなので、それに合わせて安全に変更。
スパゲッティがさらにスパゲッティに。

そして、今回味わったいろいろはすでに2年前に書いてあった。
kyobashi.dexでAndroidのBLEがつらい話してきた #kyobashidex
その上、この人の作っているBletiaは、一度目にしていたのだがスルーしていた。
しかし、改めて見てみると、すごい使いやすそう。もうこれで良かったのでは?

詳しくはQiitaへ。
posted by gpsnmeajp at 20:30| Comment(0) | TrackBack(0) | 雑感

2017年10月25日

LazyBLEWrapper v0.12公開(Indicationに対応ほか)

LazyBLEWrapper v0.12を公開しました。
micro:bitのUARTに必要だったのでIndicationに対応したほか、
UUIDのチェック用の関数、ログを黙らせる関数(正直この実装は悪手な気はしないでもない)を搭載しました。

詳しくはQiitaへ。

posted by gpsnmeajp at 14:34| Comment(0) | TrackBack(0) | 雑感

2017年10月24日

AndroidのBLEを超シンプルにするライブラリ作った(LazyBLEWrapper.java)

HPのトップページにAndroidのカテゴリが増えていたので、気づいた方もいらっしゃったかもしれませんが、新しいライブラリを作成しました。

ぼけーっとマイコンとスマートフォンをBLEでつなげてみたいなー、と思い立ち、
AndroidでBLEを使ってみようと思ったら、ちょっと眠い頭ではきついことに気づきました。

非同期処理がたくさん。シングルスレッドのマイコン頭では正直管理しきれない。
WebBluetoothは、Promiseのおかげもありますが大分シンプルなのに対し、
AndroidのBLEはなんじゃこりゃ、と思いました。

まあ、BLEもCentralだったりPeripheralだったりになれたり、色々特殊な場合も考慮しないと
いけないので、仕方ないのだとは思いましたが...

ライブラリも探しましたが、しっくり来るものもなく、仕方ないので自分好みの挙動をするライブラリを作ってしまいました。
せっかくの非同期処理を同期処理にしてしまう頭の悪いライブラリですが、もしよろしければお使いください。

詳細は以下のQiita記事をご覧ください。

AndroidのBLEを超シンプルにするライブラリ作った
https://qiita.com/gpsnmeajp/items/8fa8b3df03fb64837b44
posted by gpsnmeajp at 21:11| Comment(0) | TrackBack(0) | 雑感

2017年10月18日

PCの起動がクッソ重い問題の対処

最近、というか、クリーンインストール後から、PCの起動が遅くなった。
Core i7(4710HQ)と、メモリ16GBのマシンなのに異様に遅い。

何より困るのが、単なる起動ではなく、休止状態からの復旧時も恐ろしいほど重いということ。
タスクマネージャを見ると、CPUではなく、ディスクアクセスがフルになっているのがわかった。
HDDマシンなので、SSDにすれば解決するかもしれないが、それもなんとも言えない。

幾つか手を打つとかなり改善されたので、その手順をメモしておく。

0. タスクマネージャより、不要なスタートアップを片っ端から無効化
1. 電源オプションより「次の時間が経過後ハードディスクの電源を切る」が「1分」!?になっていたので、「60分」に変更。
2. 同じく「PCI Express」の「リンク状態の電源管理」を「最大限の省電力」から「適切な省電力」に
3. 同じく「プロセッサの電源管理」を「5%」から「20%」に
4. sfc /scannow を実行
5. dism /online /cleanup-image /restorehealth を実行
6. chkdsk /f /r c: を実行

ここまでやって、かなり改善されたが、タスクマネージャの表示が怪しかったので追加で以下を実行
7. IPv6を無効化
8. SuperFetchサービスを無効化(こいつが超絶ディスクアクセスを食う)
9. 仮想メモリの設定を8192MB固定に

これで、快適に使用できるようになった。
posted by gpsnmeajp at 19:46| Comment(0) | TrackBack(0) | 日記

2017年10月10日

FlashTools Serial Terminal v0.01

ブラウザからFlashAirのシリアルポートを叩くツールを作ってみました。無駄にArduino IDEのシリアルモニタっぽいです。
高速に受信すると取りこぼすので、実用性は不明です。



http://sabowl.sakura.ne.jp/gpsnmeajp/files/FTST.zip
posted by gpsnmeajp at 18:12| Comment(0) | TrackBack(0) | プログラム

2017年10月09日

FlashTools Lua Editor 1.07a

昨日のアップデートのデザイン変更による各種不具合の修正と、エディタのモード自動切り替えに対応。
CodeMirrorの対応する全ての形式が(Pythonとかも含め)適切に開けるようになります。
また、Filerに現在ディレクトリへのリンクを出力するようにしました。
これにより、よく使うフォルダをブラウザのブックマークに登録しておくことで即座に開くことができるようになります。
ついでに、IE使用時特有の軽微な不具合を修正しました。


更新内容
メニューに更新情報表示機能を追加
ファイルメニューのデザイン調整(iPadでの破綻対策、PCでの幅を広く、レスポンシブに、長いファイル名が切れる不具合の修正)
タイムアウト時の表示が出なくなっていた不具合修正
URLのパスを無視してルートを表示する不具合修正
フォルダパスを参照するためのリンクを追加
Loadingがなくなっていたのを修正
拡張子での編集モードの自動変更(Code mirror Lazy modeの有効化、ほぼ全ての拡張子に対応)
codemirrorを更新
インデント幅を4に変更(作者の好みです)
IEだけ..の判定が狭い不具合の修正
Remove All Filesが、IEだけ切れてキーワードが見えない不具合の修正

ダウンロード
https://sites.google.com/site/gpsnmeajp/tools/flashair_tiny_lua_editer
posted by gpsnmeajp at 16:48| Comment(0) | TrackBack(0) | 電子工作

2017年10月08日

FlashTools Lua Editor v1.07を公開

FTLEを更新しました。
主にW-04のファームウェアアップデートに伴うprint文の低速化に対応したものとなります。
ちょっとしたファイルで1分近くの読み込み時間がかかるようになってしまったため、
FTLEの読み込み機構を調整し、以前と同程度とまでは行きませんが、数秒から十数秒程度の読み込み時間で済むように調整しました。

ただ、W-04のメモリの多さに依存している機能のため、今回からW-03はサポート対象外になりました。
(一応、W-03使用時には以前と同じ動作になるように設計してありますが、積極的にサポートはしません)
またその実装上、1行に500文字以上詰め込まれたファイルは正常に読み込めない場合があります。
(メモリエラーが発生します。)

また、要望によりファイラーを強化し、ファイルの新規作成、フォルダの新規作成や、
ファイルの移動、一括削除などを画面上で行えるようにしました。割りと便利です。

また、FTLEやファイラーに、空白文字が入った時に異常動作する問題があったため、
それを修正しました。

85B58CEE-7BEB-481B-AA6D-D753F2BE517A.png

更新内容は以下のとおりです。
・W-04 4.00.01のprint文低速化に対応
・FlashTools.luaの高速化、CSSの調整
・Version判定の変更
・read.luaの高速化(24秒→1.5秒)に。(W-03はサポート対象外になりました。一応フォールバック動作します)
・ファイラーの読み込みを若干高速化
・ファイラーの拡張制限を解除
・ファイラーに新規ファイル作成・フォルダ作成・ファイル移動(名前変更)機能を追加
・ファイラーのデザインを抜本的に変更
・ファイラーおよびエディタの空白文字ファイルに対する異常動作の修正

ダウンロードはこちらから
https://sites.google.com/site/gpsnmeajp/tools/flashair_tiny_lua_editer
posted by gpsnmeajp at 23:39| Comment(0) | TrackBack(0) | 雑感

2017年10月07日

FlashTools Minimal Shell v0.01 beta

FlashAirのシリアルポートを利用した簡易シェルのベータ版を公開しました。
抜本的なリファクタリングと動的ロード機能の調整を行い、より簡単に機能拡張ができるようになりました。
所定の形式で作成したLuaスクリプトを/binに入れるだけでお好みの機能を追加することができます。
以下のGIFアニメのように、動作中にファイルが追加されても受け付けます。

クリックでフルサイズで見ることができます。
(リンクから飛んできた人は、一度ブログトップに移動してからこの記事を再度開き直す必要があるかもしれません。)
FTMS.gif

以下のテンプレートで作成されたLuaスクリプトを/binフォルダに入れてください。
便利なスクリプトができましたら報告していただけるとうれしいです。

--Description
local _name_ = "hello"
local _help_ = "hello [times] : Show \"Hello World\""

--Program
function _ (arg)
--begin user program

for i=1,tonumber(arg) do
term.print("Hello World!")
end

--end of user program
end


------------------------------------------------
--Bootstrap
shell.debugmsg(_name_," begin")
if(select(2, ...) == "help")then
shell.debugmsg(_name_," help mode")
term.print(_help_)
else
shell.debugmsg(_name_," run mode")
_(select(1, ...))
end
shell.debugmsg(_name_," end")


また、シェル機能実装にあたって通信機能の抽象化などを行いましたので、
それらを切り出してライブラリとして使っていただいても構いません。

uart.open
uart.close
uart.write
uart.writeRaw
uart.read
uart.fflush

term.setlastbuf
term.print
term.printraw
term.backspace
term.getc
term.gets

shell.setdebug
shell.debugmsg

shell.setpwd
shell.getpwd

shell.exist
shell.existDir

shell.run
shell.getAbsPath



BSD-3 Licenseです
https://sabowl.sakura.ne.jp/gpsnmeajp/files/FTMS.zip
posted by gpsnmeajp at 22:14| Comment(0) | TrackBack(0) | 電子工作

2017年10月06日

FlashTools Minimal Shellアルファ版

前回適当に作ったFlashAirのserialを使ったシェルっぽいものを、もう少し真面目に作りました。

外部コマンド実行機能をつけ、今まで内部コマンドにしていたものをほぼ全て外部化しました。
内蔵していたいろいろな関数もライブラリ化しました。
こうすることで、binフォルダにLuaスクリプトを配置するだけで、簡単に機能を拡張することができます。

tree.png

既存のLuaスクリプトも、print文をputsに置き換えてあるため、シリアルポートから結果を見ることができます。
LUA_RUN_SCRIPTにboot_shell.luaを指定することで、ブラウザレスで実行することができます。

※ファイルの一括削除などの危険なコマンドを含んでいる上に、動作保証はしませんのでご注意下さい
※ライブラリの整理をまだしっかりやっていないため、アルファ版です。今後構成等は大きく変化する予定です。

BSD-3 Licenseです
https://sabowl.sakura.ne.jp/gpsnmeajp/files/FTMS.zip
posted by gpsnmeajp at 22:33| Comment(0) | TrackBack(0) | 電子工作