• 締切済み

署名検証について

JAVAではないプログラムで取得した署名と証明書を使用して、JAVAプログラムで署名検証を行おうと思っています。 いろいろとWebで調べ、Certificateクラスを使用して公開鍵を取得しSigunature.verifyで署名を検証しようとしていますがうまくいきません。 ほかにJAVAで元データ/署名/証明書だけで署名検証できる方法はありますでしょうか?

  • tttsb
  • お礼率100% (1/1)
  • Java
  • 回答数1
  • ありがとう数9

みんなの回答

回答No.1

署名と証明書ですが、RSA、DSAなどありますがどういった方法で行っているのですか? 私も使用した事はありますが問題はありませんでしたよ。 どういった風に使用しているのでしょうか?

tttsb
質問者

お礼

遅くなりましたが、回答ありがとうございます。 現状としては検証もとの署名がリトルエンディアンで作成されているため検証が失敗しているようでした。

tttsb
質問者

補足

以下がソースコードです。 (ちょっと長いですが) /* 元データ読み込み */ byte[] data = faccess.fileread(args[0]); /* 署名データ読み込み */ byte[] sign = faccess.fileread(args[1]); /* 証明書 */ String pubcert = args[2]; /* 証明書ファイルストリーム生成 */ FileInputStream fis = new FileInputStream(pubcert); /* 証明書ファクトリオブジェクト生成 */ DataInputStream dis = new DataInputStream(fis); CertificateFactory cf = CertificateFactory.getInstance("X.509"); byte[] bytes = new byte[dis.available()]; dis.readFully(bytes); ByteArrayInputStream bais = new ByteArrayInputStream(bytes); while(bais.available() > 0){ /* 証明書取得 */ Certificate cert = cf.generateCertificate(bais); /* 公開鍵取得 */ PublicKey pubkey = cert.getPublicKey(); /* 署名オブジェクトを生成する */ Signature sig = Signature.getInstance("SHA1withRSA"); /* 公開鍵証明書での検証 */ /* 署名検証準備 */ sig.initVerify(cert); sig.update(data); /* 署名検証 */ boolean result = sig.verify(sign); System.out.println(result); /* Certificateで取得した公開鍵での検証 */ /* 署名検証準備 */ sig.initVerify(pubkey); sig.update(data); /* 署名検証 */ /*boolean*/ result = sig.verify(sign); System.out.println(result); faccess.filereadはファイルからバイトデータを 取得する関数です。 署名方法はRSAで行っています。

関連するQ&A

  • 署名と検証

    http://java.sun.com/j2se/1.4/ja/docs/ja/guide/security/CryptoSpec.html を読んで、ある文章への署名の方法はわかりました。 だた、検証の方法がわからないんです。 例えば、あるプログラムで署名されたファイルを 違うプログラムで検証するにはどうしたらいいのでしょうか? 秘密鍵の生成などはわかったのですが、 どのようにして、署名をした人でない人が 公開鍵を受け取って検証するのでしょうか? この公開鍵の受け取り方がわかりません。 どうかよろしくお願いします。

    • ベストアンサー
    • Java
  • 電子署名 RSAとDSA

    電子署名の一般的な説明のポンチ絵では以下のように説明されますが、これはRSAを用いた場合であり、DSAではないという理解で正しいでしょうか? ---- 送信者が文書のハッシュ値を秘密かぎで暗号化して電子署名を作成し、文書と電子署名と公開かぎ証明書を相手に送付する。 受信者は公開かぎ証明書を検証後、電子署名を復号化したものと、文書のハッシュ値を比較する。 ---- DSAは署名データをもとにもどせませんからね。

  • ディジタル署名の質問

    <@ITから引用>ディジタル署名の場合,メッセージは送信者の公開かぎで復号する。公開かぎは一般に公開されるものなので,だれでも暗号文を復号できる。そのため,Webサーバが不特定多数のクライアントに対して自分自身を証明する用途などに使われる ここでディジタル署名の質問なのですが、上記の「だれでも暗号文を復号できる」のでは暗号の意味がないと思うのですが。 自分で考えたのですが、不特定多数とあるようにクライアント(受信者)を特定してはいないということですか?Webサーバ(送信者)は自分自身を証明するとあるのでまず、サーバの秘密カギはサーバを特定しますよね。 詳しく教えてくれると助かります。

  • 自己署名証明書によるSSL通信について教えてください!

    SSL通信により、データを暗号化してWeb上でやりとりするシステムの構築を考えています。 そこで自己署名というのを考えているのですが、署名の流れがいまいち分かりません。 認証局利用の場合、私の理解では、 【サーバ側】 1.サーバ側でRSA秘密鍵を生成 2.RSA秘密鍵を元にCSRを作成 3.CSRファイルを認証局に送信 【認証局】 4.CA秘密鍵により暗号化し、サーバ証明書を作成 5.サーバ側にサーバ証明書を送信 【サーバ側】 6.クライアント側にサーバ証明書を送信 【クライアント側】 7.サーバ側よりサーバ証明書を受信する 8.認証局より公開鍵を取得する 9.認証局の公開鍵でサーバ証明書の暗号化された鍵(認証局の秘密鍵で暗号化されたもの)を復号する 10.復号した鍵により、サーバ証明書の暗号文を復号する となります。(間違いがある場合はご指摘下さい) では、自己署名を行う場合はどうなるのでしょうか? 単純にサーバ証明書を自分で作成すると考えてよろしいのでしょうか? CSRファイルの作成などもやはり行うのでしょうか? クライアント側の流れは変わらないのでしょうか? また、この操作は接続毎に毎回行うことになるのでしょうか? (秘密鍵、サーバ証明書は毎回変わるのでしょうか?) 初歩的な質問とは思いますが、よろしくお願いいたします。

  • デジタル署名のプロセスについて

    次の選択肢の中で、デジタル署名のプロセスとして正しいものはどれか教えて下さい。 1.ハッシュ関数で元データをダイジェストという文字列に変換する→それを自分のプライベート鍵で暗号化する 2.ハッシュ関数で元データを圧縮する→それを自分の公開鍵で暗号化する 3.元データを自分のプライベート鍵で暗号化する 4.元データを自分の公開鍵で暗号化する 5.元データを自分のプライベート鍵で暗号化する→それをハッシュ関数で圧縮す る

  • メールのデジタル署名は、なぜ本文を暗号化しないの?

    デジタル署名の仕組みについて教えてください。 デジタル署名の仕組みは、メールの内容(原文)からメッセージダイジェストを作成し、それを送信者の秘密鍵で暗号化したものを署名として原文(または暗号文)に付けるということですが、どうして単に原文そのものを暗号化したものを署名として送らないのでしょうか? 改ざん防止の為であれば、原文そのものを暗号化して送れば、受信側で改めてメッセージダイジェストを作成し、それと復号化したメッセージダイジェストを突き合わせて検証するようなことをしなくても済むと思うのですが。 いづれにしても公開鍵で復号化できるということは、秘密鍵を持っている送信者が署名した段階から改ざんされていないはずですし、その公開鍵が証明書等により検証できていれば、確かに本人であるということになりますよね。 現実世界の「署名」のように、署名とは原文とは別につけるもの(=わざわざ復号化しなくても原文が読める)、いうことに似せているだけのことでしょうか? (参考URL) http://www.ipa.go.jp/security/awareness/administrator/remote/capter6/7.html

  • 認証局の認証局?

    PKI等で使われる電子証明書について教えてください。 認証局が発行する電子証明書には、認証局の電子署名が入っているそうですが、その署名はどうやって検証するのでしょうか?検証するためには、認証局の公開鍵すなわち認証局の電子証明書が必要になり、その中には、また別の電子署名があると思いますので、その電子署名を検証しないといけないと思います。 こう考えると、いつまでたっても証明できないような気がしますが... また、電子証明書の電子署名とは、電子証明書データのハッシュ値を暗号化したものと考えればよいでしょうか?

  • APKファイルに署名をつけると複数署名になります

    APKファイルに署名をつけるためにkeytoolで jarsigner -verbose -keystore c:\ディレクトリ\証明書名.keystore c:\ディレクトリ\アプリ名.apk o証明書別名 や jarsigner -keystore 証明書名.keystore -digestalg SHA1 アプリ名.apk 証明書別名 jarsigner -verbose -keystore 証明書名.keystore -storepass パスワード1 -keypass パスワード2 -signedjar アプリ名.apk aアプリ名2.apk 証明書別名 を実行したら jarsigner:java.lang.SecurityException: invalid SHA1 signature file digest for n ・・・es/layout/main.xml というエラーが出てうまく署名できませんでした そこで jarsigner -sigalg SHA1withRSA -digestalg SHA1 -keystore 証明書名.keystore -verbose アプリ名.apk 証明書別名 で署名をつけるとあの忌々しいメッセージは表示されなくなり 「jarが検証されました」といううれしいメッセージが表示されるようになりました しかしなぜか二重署名になってしまい、やはりGooglePlayにアプリを 登録する事はできませんでした jarsigner -verify -verbose -certs アプリ名.apk で確認すると 当方がつけた署名以外に X.509, CN=Android Debug, O=Android, C=US [証明書は11/11/02 3:15から41/10/25 3:15まで有効です] という署名がついて複数署名になっています また、 [CertPathが検証されていません: Path does not chain with any of the trust a ors] というエラーが署名の箇所に表示され文末には このjarには、証明書チェーンがまだ検証されていないエントリが含まれています と表示されています なぜこのようなエラーが出るのか、複数署名になるのを防ぐ事はできるのか もしおわかりになりましたらご指導下さい お忙しい中ご面倒をおかけ致しますが何卒よろしくお願い申し上げます

    • ベストアンサー
    • Java
  • 自己署名証明書(オレオレ証明書)の暗号化について

    SSL暗号化通信の仕組み自体は,下記URLの通りとして把握しております. (1*) http://www.twsvc.com/about_ssl (2*) http://www.ibm.com/developerworks/jp/websphere/library/web/web_security/pdf/2_6.pdf これを,オレオレ証明書を用いた暗号化通信で考えると,セキュリティに関する識者である高木氏は,自分の日記にて以下のように書いています. >共通鍵暗号による暗号化通信をしています。鍵は一緒に配送します。この暗号は正常に機能しているでしょうか? >「今の話は共通鍵暗号じゃなくて公開鍵暗号だろ」って? オーケー、では、次の比較に対してどう答えるか。 >1.共通鍵暗号による暗号化通信 >2.公開鍵暗号による暗号化通信で認証なし(認証検証時の警告を無視する使用形態) >3.公開鍵暗号による暗号化通信で認証あり (略) >では、1.と 2. を比べたときはどうか。「3.ほどではないが 1.よりは 2. の方がまし」と言えるだろうか? それは誤りである。 (略) >公開鍵暗号の公開鍵がいっしょに配送されている暗号化通信では、傍受点で、流れてきた鍵を、別途用意した自作鍵に差し替えて流してしまえば、それで暗号化されて戻ってくる暗号文を復号できる。 ※詳細は,高木氏の「PKIよくある勘違い(1)「オレオレ証明書でもSSLは正常に機能する」」をご参照ください. ここで,疑問になるのが,”傍受点で、流れてきた鍵を、別途用意した自作鍵に差し替えて流してしまえばいい”という点です. オレオレ証明書では,ルート証明書にたどり着けないため,ブラウザはオレオレ認証局の公開鍵をもっていない. そのため,サーバ証明書内の公開鍵を取得できない. だから,サーバ証明書送付時にオレオレ認証局の公開鍵を送付する必要がある. オレオレ認証局の公開鍵を用いて,サーバ証明書から公開鍵を抜き出す もしこのとき,オレオレ認証局の公開鍵が自作鍵に置き換えられたとしても,ただ単にサーバ証明書から公開鍵を抜き出すことができず,そこで通信が終了すれば”それで暗号化されて戻ってくる暗号文を復号できる”ことも無いように思えるのですが,いかがでしょうか. (つまり,高木氏の言う差し替えた自作鍵でサーバ証明書内の公開鍵が取得できるかどうか) これができなければ,確かに暗号化通信(というか通信そのもの)自体は破綻していますが,高木氏の懸念しているような「重要な情報の流出」にはつながらないように思えます. 乱文になってしまいまして申し訳ありません. もし,私自身に勘違いや解釈違い等ありましたら,ご指摘いただけると幸いです. よろしくお願いします.

  • HTTPS(SSL)の仕組みとセキュリティについて

    SSLの仕組みと,そのセキュリティについての質問です. 現在,HTTPSで利用するSSLの仕組みについて勉強をしています. しかしながら, 自身がSSLの仕組みについて正しく理解できているか分かりません. また,どうしても理解ができない点が何個かあり,質問させて頂く次第になりました. (様々な書籍やwebを拝見したのですが,いづれも腑に落ちませんでした...) そのため,まず大まかに私が理解しているHTTP上のSSLの仕組みを書き,最後に質問を書かせて頂こうかと思います. 長くなりますが宜しくお願い致します. ■主な登場人物 ・認証局  CA秘密鍵  CA証明書(公開鍵?)  CA証明書発行要求  ・証明書  KEYファイル(秘密鍵/公開鍵)  CSRファイル/申請書(issuer側の情報/公開鍵)  CRTファイル/サーバー証明書(CSRを認証局の秘密鍵で捻ったモノ) ■証明書の発行 1-1.証明書を発行したい者がCSRファイルという申請書を作成し,認証局に送ります.    →CSRには登録情報(issuer)やサーバー(証明書を発行したい者)の公開鍵などが含まれます. 1-2.認証局はCSRファイルが適切であれば,署名(subject)し,認証局の秘密鍵でCSRの中の公開鍵のみを暗号化します. 1-3.これがCRTファイルになり,証明書を発行したい者に送り返されます. この時,サーバー(証明書を発行した者)は認証局によって署名されたCRTファイルを持っています. 次にこれを利用したHTTPS通信について書きます. ■HTTPS通信 2-1.クライアントがサーバーに通信要請をします. 2-2.サーバーは証明書(CRT)をクライアントに送ります. 2-3.クライアントは送られてきたCRTが信頼できるか認証局の証明書(公開鍵)を使って検証します.    →CRTに埋め込まれているサーバーの公開鍵は認証局の秘密鍵によって暗号化されているので,これを認証局の公開鍵で複合化します.    →認証局の公開鍵はルート証明書といい,事前にブラウザに組み込まれているものとします. 2-4.クライアントは共通鍵を発行します. 2-5.クライアントはCSRから複合化したサーバーの公開鍵を用い,自身で発行した共通鍵を暗号化してサーバーに送ります 2-6.サーバーは受け取った暗号データを自身の持つ秘密鍵で複合化し,共通鍵を取得します. 2-7.後はこの共通鍵でデータを暗号化し通信します, ■質問 1.オレオレ証明書+認証局の場合でも正常に通信ができるのはなぜか 私の理解だと2-3で,クライアントが認証局の公開鍵を用い,サーバーの証明書からサーバーの公開鍵を複合化し,それを元に共通鍵を暗号化しています. これはクライアントが認証局のルート証明書(公開鍵)を保有しているから複合化できるはずです. オレオレ証明書の場合は,認証局の公開鍵がクライアントにインストールされていません. そのため,サーバーの公開鍵を複合化できず,共通鍵の生成に失敗し,通信できなくなると思います. しかしながら,ブラウザは「署名が不明な接続先です」とのエラーを出すだけで,通信(接続)ができてしまいます. なぜでしょうか. 2.IssuerとSubjectは暗号化されていないのか 私の理解だと1-2の認証局では,サーバーの公開鍵しか暗号化されていません. ということはIssuerとSubjectは暗号化されていないということでしょうか. また,それはなぜでしょうか. 3.IssuerとSubjectは偽装できるか opensshを用いることで認証局を構築することができます. この時に,Subjectの設定をベリサインの認証局と全く同じようにし, 証明書も,ベリサインの認証局を使っているサイトのIssuerと全く同じようにした場合, SubjectとIssuerが全く同じ証明書ができると思います. この場合は,本物の証明書と同様の証明書を複製できてしまうのでしょうか. できないとは思いますが,それはなぜでしょうか. 4.証明書の偽装は可能か ブラウザから証明書の情報を見ることができます.もちろんbyteデータのraw certificateも見ることができます. この情報を丸々コピーし,全く異なるサーバーに証明書として読みこませて通信した場合は, 署名されてしまうのでしょうか. されないとは思いますが,それはなぜでしょうか. (例えば,URL=CN情報が異なっているから確認できるとか..?それならCN情報だけ書き換えてしまえばいい?) 5.証明書の検証をするにはどうしたらよいか 証明書を検証をするには,その証明書を発行した認証局の公開鍵を利用するしかないのでしょうか. 例えば,サーバー証明書(CRT)のフィンガープリントsha1データを事前に保持さえしていれば, サーバーに証明書を示された際にCRTのフィンガープリントを比較すれば,特定のサーバーかどうか検証できるか・・? 6.MITMについて MITM攻撃により,証明書が途中で書きかわることが考えられます. この場合は,書き換わった証明書をどのように特定すればいいのでしょうか. 例えば,認証局のルート証明書がないなどが考えられますが, 仮に,Rapid SSLなどで署名されている証明書でMITM攻撃がされた場合どうなるでしょうか? この場合は,Issuerなどを比較するしかないように考えられます. しかし,Issuerはcsr申請の際にうまいこと,書き換えることができてしまいます. そう考えると,どのような対策ができるでしょうか フィンガープリントなどで比較することになるのでしょうか, フィンガープリントは偽装することができないのでしょうか. 以上となります. 様々な質問を書いてしまい,申し訳ありません 説明不足で乱文だとは思いますが, 分かる範囲でお答え頂けませんでしょうか. 宜しくお願い致します.