「フィンガープリント」を含む日記 RSS

はてなキーワード: フィンガープリントとは

2024-07-09

フットプリントフィンガープリント

フットプリントは「足の大きさ」転じて面積の意。

フィンガープリントは「指紋」転じて個人情報の意。

なんでフットプリントでは個人特定できないのか…採るのは楽そうなのに…

2024-05-11

デバイス情報: システム & CPU 情報

Device Info は、高度なユーザー インターフェースウィジェット使用してモバイルデバイスに関する完全な情報提供するシンプルで強力な Android アプリケーションです。たとえば、デバイス情報/ 電話情報には、CPURAMOSセンサストレージバッテリーSIMBluetoothネットワークインストール済みアプリシステム アプリディスプレイカメラ温度などに関する情報が含まれます。また、デバイス情報/ 電話情報は、ハードウェア テストデバイスベンチマークを行うことができます

中身 : 👇 👇

👉 ダッシュボード : RAM、内部ストレージ、外部ストレージバッテリーCPU、利用可能センサインストール済みアプリ & 最適化

👉 デバイス : デバイス名、モデルメーカーデバイスボードハードウェアブランド、IMEI、ハードウェア シリアルSIM シリアルSIM サブスクラバーネットワークオペレータネットワークタイプWiFi Mac アドレスビルドフィンガープリント & USB ホスト

👉 システム : バージョン、コード名、API レベルリリース バージョン、1 つの UI バージョン、セキュリティ パッチ レベルブートローダー、ビルド番号、ベースバンドJava VMカーネル言語ルート管理アプリGoogle Play サービスバージョン、Vulkan のサポート、Treble、シームレス更新OpenGL ES およびシステム稼働時間

👉 CPU : Soc - システム オン チッププロセッサCPU アーキテクチャサポート対象ABICPU ハードウェアCPU ガバナー、コア数、CPU 周波数、実行中のコア、GPU レンダラーGPU ベンダー & GPU バージョン

👉 バッテリー : ヘルスレベルステータス、電源、テクノロジー温度電圧と容量

👉 ネットワーク : IP アドレスゲートウェイ、サブネット マスクDNSリース期間、インターフェイス周波数リンク速度

👉 ネットワーク : IP アドレスゲートウェイ、サブネット マスクDNSリース期間、インターフェイス周波数リンク速度

👉 ディスプレイ : 解像度密度フォント スケール物理サイズサポートされているリフレッシュレート、HDRHDR 機能、明るさのレベルモード、画面のタイムアウト、向き

👉 メモリ : RAMRAM タイプRAM 周波数ROM、内部ストレージ、外部ストレージ

👉 センサー : センサー名、センサベンダーライブセンサ値、タイプ、電力、ウェイクアップセンサダイナミックセンサ、最大距離

👉 アプリ : ユーザーアプリインストール済みアプリアプリバージョン、最小 OSターゲット OSインストール日、更新日、アクセス許可アクティティサービスプロバイダレシーバー抽出アプリ Apk

👉 アプリアナライザー : 高度なグラフ使用して、すべてのアプリケーション分析します。また、ターゲット SDK、最小 SDKインストール場所プラットフォームインストーラ、および署名によってグループ化することもできます

👉 デバイス テスト

ディスプレイマルチタッチ懐中電灯、ラウドスピーカー、イヤースピーカーマイク、耳近接、光センサ加速度計、振動BluetoothWI-Fi指紋、音量アップボタン、音量ダウンボタンテストできます

👉 温度 : システムによって指定されたすべての温度ゾーンの値

👉 カメラ : カメラサポートするすべての機能

👉 テーマ : ダークテーマカスタムカラーサポート

👉 カスタマイズ可能ウィジェット : 最も重要情報を表示する 3 つのサイズの完全にカスタマイズ可能ウィジェット

👉 レポートエクスポートカスタマイズ可能レポートエクスポートテキストレポートエクスポートPDF レポートエクスポート

権限 👇 👇

READ_PHONE_STATE - ネットワーク情報を取得するには

CAMERA - 懐中電灯テスト

RECORD_AUDIO - マイクテスト

BLUETOOTH_CONNECT - Bluetooth テスト

READ_EXTERNAL_STORAGE - イヤースピーカーとラウドスピーカーテスト

WRITE_EXTERNAL_STORAGE - アプリ抽出

2023-04-28

Chromeキャッシュ嘘容量に怒ってるやつ集まれ

https://b.hatena.ne.jp/entry/s/blog.hinaloe.net/2023/04/27/chrome-too-large-cache-storage/

特に偽装するな!みたいな怒り方してるコメントはわりと筋違いでは。

そもそもITではセキュリティ観点情報偽装するのは日常なわけだが、サーバーバージョン情報を隠したり偽ったりするのは日常だし

サーバー側だけじゃなくパラノイアユーザーは常にUA偽装してWebを閲覧してるし、送信先からやってくる情報はいだって正直なデータじゃなくて偽装されてる可能性がある(これは通信経路で改ざんされてるって意味じゃないよ)

だってfirefoxアドオン入れてEdgeのフリしてBing AIチャット動かしてるしな

その点についての指摘は、見当違いだろっていう

特にBingチャット使いたい〜みたいなしょうもない理由改ざんしてる俺なんかよりは、セキュリティのためにAPIの値を偽装してるChromeの方が全然マシな理由偽装してるわけで、フィンガープリント防いでくれてありがとうくらいは言ってもいいんじゃないかね

もちろんそれが、ブラウザ管理画面にの数字に判定されてるChrome仕様はアホでそれを叩くのは筋が通ってる

なので、要約すると

ということになるのでは?

しらんけど

2023-01-07

anond:20230107161923

ブラウザフィンガープリントっていう技術がある。匿名モードでは一発で特定可能情報は送っていないのだが、画面サイズIPアドレス、GeoLocation、ブラウザバージョンOSインストールしている拡張機能、とかを組み合わせるとかなり絞れてしまう。

2021-11-16

anond:20211116020200

どうせBT使って近隣のスマホ通信してるんだろ

そのスマホで一度でもグーグルログインしたら機種固有のフィンガープリントを把握されてるからログアウトしても無意味だと思うわ

2021-06-20

ランダム増田ID登録メアドプロフィールデジタルフィンガープリントを公開する様にしようぜ

スリリングだろう?

いつ自分が晒されるかわからないスリル…たまんねぇ!

その中で犯罪予告まがいや多方面ケンカ売る事書くんだ、これはもうロシアンルーレット以上の快楽だッ!

2021-04-12

anond:20210412134937

AI技術が発達した昨今では、あらゆる挙動からフィンガープリントが集められて個人特定される時代です。

あなたがどんなに自分個人情報を出さないように努力していても、世界のどこかから漏れ出てくるのです。

そして、それは容易に特定されてしまうのです。

2020-10-20

"フンガープリント"

次の検索結果を表示しています: "フィンガープリント"

元の検索キーワード: "フンガープリント"

"フンガープリント"

約 103 件 (0.36 秒)

もしかして: "フィンガープリント"

2020-01-16

anond:20200116231450

ソースコードレベルでのGPLもそうだし

バイナリになっていても有名なGPLフィンガープリント技術で検出できるし

検出できるからこそGNUとかが警告するというのがある。

2019-10-24

はてなフィンガープリント採取問題ではないのか?

はてなフィンガープリント採取

u.openx.netがあるけど、

hatena-d.openx.netであるな。


はてなは、はてブボタンスパイウェアを埋め込んで大問題になったことがあったよね。

それで、フィンガープリント採取hatena-d.openx.netでしてるんだな。


facebook個人情報取得で大問題になったし、

国内でも、はてブでは、価格コム検索タグ指定をしてるとかで問題にしてたな。

食べログがどうとか、他のサイトにはよく批判してるが。


何で、日本国内個人情報取得とかで、はてなには大甘なんだろうね?

はてブPVが欲しいからって、IT系ネットサイトまで、はてなに遠慮してきたのは何だろう?


幽霊だったかを書いていて問題になったWELQとかあったが、

はてブスパイウェアボタンのほうが大問題だと思うけどスルーされて、

今度は、フィンガープリント採取hatena-d.openx.netスルーするのかな?


フィンガープリントって、当然だけど、普通クッキーとは違うからね。

クッキーでも問題だという声もあるのに、

フィンガープリントなんか、クッキーよりよっぽど個人に紐づいて

離れないし、はてなhatena-d.openx.netを何に使っているか

言うべきではないのか?


はてなは、個人情報取得とかしても

結局、はてブボタンでもサイトが存続できたことをいいことに、

フィンガープリント採取もしてるんじゃない?

2016-10-17

How the Textsecure Protocol (Signal, WhatsApp, Facebook, Allo) Works

http://www.alexkyte.me/2016/10/how-textsecure-protocol-signal-whatsapp.html これエキサイト翻訳か?主語が全部theyという支離滅裂英語なんだが。

----

TextSecureの目標は「経路末端までのセキュリティ否認性、前方秘匿性、将来の秘匿性のすべて」を提供することである。具体的には、可能な限り短い時間だけ鍵情報を保持するメッセージストリームを二者の間に構築するということを目指す。将来に鍵の危殆化があっても、現在観測されたトラフィックを復号化できなくするのだ。

以下にSignal Protocolの批評分析を羅列してある。実装構造研究し、発見した欠陥を記述し、上述の目標がどれほど実現されているか評価するものである。まず仕組みの説明をしてから、より詳細な分析を続けることにする。

用語

TextSecureは、今ではSignalと呼ばれているアプリに与えられた名の一つだ。コード文書も一貫してTextSecureという名を使っている。一貫性を保つため、システム全体をTextSecureと呼ぶことにする。

ただ実際には数々の異なるものが含まれている:

構造

TextSecureは、非同期整合性に焦点を当ててOff-The-Recordというチャットプロトコルを改造したものだ。OTRが対話ハンドシェイク必要とする一方、TextSecureは不確定な遅延を認めない。メッセージを送れるようになるまでアプリを表示したままにしてハンドシェイク遂行しなければならないというのであれば、ユーザ体験はひどいことになる。

そうではなく、通常の鍵交換においてサーバが果たす役割の部分だけ、将来のクライアントが取得しに来るよう中央サーバに格納される。このサーバは、すべてを復号化できる鍵情報は預けておかない、信用なし経路となる。すべての暗号化は末端どうしだ。

暗号

TextSecureは暗号学の基礎のほんの一部を使うものである公開鍵暗号は楕円Diffie-Hellmanを通し、Curve25519を用いて実行される。AESがパディングなしカウンター(CTR)モードサイファーブロックチェーン(CBC)モードの双方で対称暗号に使われる。HMAC-SHA256がメッセージ認証に使われる。これらが信頼の基礎(TCB)である

ダブルラチェット:

TextSecureの暗号化エンジン中心部はAxolotlダブルラチェットアルゴリズムである。大まかに言うと、一方向にだけ回ることのできるラチェットが二つあり、一つは受信ラチェット、もう一つは送信ラチェットである。この構造により、鍵交換の前半を保管しておいて、後から非同期的に再生し完全なハンドシェイクを得ることが可能になっている。

受信ラチェットメッセージが受信されるときに使われるが、そこには次の鍵交換のための新しい材料が含まれていなければならない。この材料が後ほど暗号化メッセージ認証に使う対称鍵の生成に用いられる。

送信ハッシュラチェットは前回の整合性ある共有秘密から生成された鍵ストリームを使って新たな鍵セットを生成する。このラチェットは、受信ラチェットが進んで共有秘密が変化するとリセットされる。

ここで注目すべきは、メッセージ送信するために送信者が待つ必要は一切ないということだ。いつでも送信第一歩を踏み出すことができ、その一歩は必ず有限の時間で終わる。メッセージはすべて異なる対称鍵で暗号化されるが、これにより、ある時点の鍵は、どちら側のデバイスのものであっても、過去送信されたメッセージを復号化するためには使えないことになる。(ただし後で一つ警告がある。)

プロトコル

フェーズ1: TextSecure登録

登録は、クライアントに言って、連絡用の電話番号サーバに教えてもらうことから始まる。また同時に、トークン通話SMSどちらで受け取りたいか希望登録してもらう。このトークンが持ち主の証明となり、TextSecureで情報登録できるようにしてくれる。

クライアントメッセージ認証暗号化の対称鍵('signaling'鍵)、および長期公開鍵を送る。

また、複数のプレ鍵も送信する。これはクライアントが受信者になる時の鍵交換の半分、クライアント側部分の使い捨てコピーである。こうして保管されているプレ鍵のおかげで、将来の送信者はクライアントの応答を待つ必要もなく鍵交換を完了でき、こうして遅延を劇的に減らすことができる。クライアントは「最後の手段のプレ鍵」もアップロードするが、これは最後に使われ、受信者が新しいプレ鍵を追加するまでのセッションでずっと共有され続ける。

他のクライアントからも使われるプレ鍵に頼ることについてSignalが警告をしないというのは、筆者の意見では、理想と程遠い。

クライアントは次にGoogle Cloud Messagingに登録して、登録IDをTextSecureに出す。このTextSecureへの登録には、クライアントSMSを受け取りたいかデータだけにしたいか情報も含まれる。

フェーズ2: 鍵の比較

TextSecureはクライアントどうしがお互いの長期鍵のフィンガープリント比較して本人確認できるようになっている。鍵をQRコードとして表示して便利に検証できるようにする機能も含まれている。

フェーズ3.1: 最初メッセージ送信

送信者は、まず相手のプレ鍵を要求し、プレ鍵インデックス、プレ鍵、登録ID、長期公開鍵をもらう。これらを使い、HKDFという鍵派生アルゴリズムを通して共有秘密を取り決める。この秘密情報ルート鍵と呼ぶ。

このメッセージだけの一時鍵ペアが生成される。ルート鍵を使ってHKDFで新しいルート鍵とつなぎ鍵を派生させる。このつなぎ鍵は、暗号化MACの鍵を生成するのに使われる。

最後AESカウンター初期化される。カウンターは二つある: ctrとpctrだ。ctrカウンターメッセージ送信ごとに増える一方で、pctrカウンターは、最後既読メッセージの番号を保持する。これにより、受信者側にバラバラの順番で届いたメッセージを正しく並べ直すことができる。

これらを使って相手メッセージ暗号化し、それをSignalサーバに送る。このメッセージには、相手が鍵交換ハンドシェイク完了できるだけの必要情報が含められている。

SignalサーバGoogle Cloud Messenger登録IDが件の電話番号に合っているかチェックし、メッセージを'signaling'鍵で暗号化してからクラウドサーバに送る。この遠回しな方法により、Google Cloud Messengerがメッセージ送信元を知らずにいることが保障される。

フェーズ3.2: メッセージ受信

信者はプレ鍵インデックスを受け取り、送信者がどのプレ鍵を使ったかをそれで調べる。そして送られてきた情報を使ってハンドシェイク完了したり送信者と同じルート鍵を持ったりする。送られてきたメッセージを復号化するために使う鍵は、このルート鍵が生成する。

フェーズ4: 追伸メッセージ送信

相手が返信する前に、もとの送信から続きのメッセージを送りたい場合は、新しいつなぎ鍵を生成して、これを使って新しい暗号化およびメッセージ認証の鍵を得る。

フェーズ5: 返信の送信

信者が返事を出したい時は、まず新しい一時鍵ペアを選ぶ。送信者の一時公開鍵自分の一時秘密鍵を使って、新しい共有秘密を生成する。これを使って新しいつなぎ鍵を得て、そこから新しい暗号化認証の鍵を得る。これを使ってメッセージ暗号化し、さきほどの新しい一時公開鍵と一緒に送信する。

既知の問題

鍵の提出

TextSecureは、サーバクライアント間の共有秘密、いわば機械生成パスワードを使って、新しいプレ鍵のアップロード認証する。これは送信メッセージ認証にも使われる。このパスワードを漏らしてしまうと、それだけでメッセージ送信も鍵アップもそのユーザなりすましてできてしまうことになる。エキスポート機能があった頃はTextSecureクライアントを別のスマホに移行することができたが、この機能は削除された。エキスポート情報には機械生成パスワードが含まれていたからだ。この平文バックアップデバイスSDカードに置かれていたので、他のアプリから読むことができたのだ。

この機能はそれ以来削除されたままだ。なくて困る人がいるとしても、これはユーザビリティ問題ではなく、現実問題であり、それに対する後ろ向きな対策なのである

未知の鍵共有 (UKS) 攻撃

この攻撃は偽配送一種だ。攻撃者がUKS攻撃を実行すると、ある送信者が攻撃者に向けて送ったつもりのメッセージが、攻撃から別の人(標的)へのメッセージとして送信される。

これは能力のある攻撃者にとっては簡単にできる。TextSecureサーバ上にある自分公開鍵を、標的の公開鍵に変えればいい。これは自分電話番号を再登録すればできる。送信者はQRコードを使って、相手フィンガープリントが合っていることを検証できるが、これが本当に標的の鍵のフィンガープリントになるのである

それから、今度は送信者のアカウントを再登録して、その検証SMS確認通話送信者に到達しないよう横取りしなければならない。これは太っ腹に権限を与えられた人には造作もないことだ。こうして、送信者として認証し、既知の署名つきメッセージ送信できるようになる。

この攻撃はTextSecureでは解決されていない。プレ鍵の署名は追加したが、まだ暗号学的にIDと関連付けられているわけではないので、奪われて再生される危険がある。

できることがあるとすれば、送信者と受信者の双方がメッセージ暗号化された本文内で言及されるようにすることなどだ。

目標達成率

TextSecureはその構造のおかげで前方秘匿性を獲得している。前方秘匿性(forward secrecy)は、もし長期公開鍵安全なままであれば、ある時点の対称鍵が漏れても、そのセキュリティ突破限定的時間範囲しか有効でないとする。新しいラチェットのそれぞれに公開鍵必要であることから、これは達成されている。

完全前方秘匿性(perfect forward secrecy)は、クライアントの持つある時点の鍵が奪取されても、それ以前に送信したメッセージの復号化が不可能である性質定義されている。このことはTextSecureのwire protocolにより施行されるが、少々ことば遊びに入ってくる。というのも鍵はデバイスにのみ格納されているので、アプリ上の他の鍵にアクセスすることなく鍵が暴露されることはありそうにない。長期鍵だけではメッセージを復号化できず、ラチェットステート対応する一時鍵が必要になるが、これはそのスマホから引き出すことができるので、送信したものの返信されていない(前回のラチェット使用した)メッセージを復号化できる。これは技術的に言えば「以前の」メッセージ暴露である

否認性(アリバイ)はさらあやふやだ。ある特定メッセージについて、それはだれにでも作成できたのだと言うことは可能だが、その一方で、プレ鍵は公開されているので、TextSecureの中央集中構造が脅威をもたらす。TextSecureサーバ認証メッセージ転送をするものだが、それを記録することもできる。内容は末端どうしで暗号化されているとはいえ、メタデータは違う。

Sources

Analysis Whitepaper:

http://ieeexplore.ieee.org/document/7467371/

Marlinspike, Moxie (30 March 2016). "Signal on the outside, Signal on the inside". Open Whisper Systems. Retrieved 31 March 2016. https://whispersystems.org/blog/signal-inside-and-out/

Posted by Alexander Kyte at 11:47 PM

 
ログイン ユーザー登録
ようこそ ゲスト さん