Menu
▾
▴
opensc-devel — discussion of developement of OpenSC and related projects
You can subscribe to this list here.
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2013 |
Jan
(26) |
Feb
(64) |
Mar
(78) |
Apr
(36) |
May
(51) |
Jun
(40) |
Jul
(43) |
Aug
(102) |
Sep
(50) |
Oct
(71) |
Nov
(42) |
Dec
(29) |
| 2014 |
Jan
(49) |
Feb
(52) |
Mar
(56) |
Apr
(30) |
May
(31) |
Jun
(52) |
Jul
(76) |
Aug
(19) |
Sep
(82) |
Oct
(95) |
Nov
(58) |
Dec
(76) |
| 2015 |
Jan
(135) |
Feb
(43) |
Mar
(47) |
Apr
(72) |
May
(59) |
Jun
(20) |
Jul
(17) |
Aug
(14) |
Sep
(34) |
Oct
(62) |
Nov
(48) |
Dec
(23) |
| 2016 |
Jan
(18) |
Feb
(55) |
Mar
(24) |
Apr
(20) |
May
(33) |
Jun
(29) |
Jul
(18) |
Aug
(15) |
Sep
(8) |
Oct
(21) |
Nov
(5) |
Dec
(23) |
| 2017 |
Jan
(3) |
Feb
|
Mar
(17) |
Apr
(4) |
May
|
Jun
(5) |
Jul
(1) |
Aug
(20) |
Sep
(17) |
Oct
(21) |
Nov
|
Dec
(3) |
| 2018 |
Jan
(62) |
Feb
(4) |
Mar
(4) |
Apr
(20) |
May
(16) |
Jun
|
Jul
(1) |
Aug
(9) |
Sep
(3) |
Oct
(11) |
Nov
|
Dec
(9) |
| 2019 |
Jan
(1) |
Feb
(1) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
(5) |
Nov
|
Dec
(5) |
| 2020 |
Jan
(11) |
Feb
(14) |
Mar
(7) |
Apr
|
May
|
Jun
(3) |
Jul
(3) |
Aug
(6) |
Sep
(2) |
Oct
(15) |
Nov
(11) |
Dec
(7) |
| 2021 |
Jan
(14) |
Feb
(21) |
Mar
(3) |
Apr
(1) |
May
(1) |
Jun
|
Jul
(1) |
Aug
(1) |
Sep
(3) |
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
(12) |
Dec
|
| 2023 |
Jan
(2) |
Feb
(4) |
Mar
|
Apr
(8) |
May
|
Jun
(2) |
Jul
|
Aug
(3) |
Sep
(1) |
Oct
|
Nov
(1) |
Dec
(1) |
| 2024 |
Jan
|
Feb
(2) |
Mar
(6) |
Apr
(1) |
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
(4) |
Dec
|
| 2025 |
Jan
(1) |
Feb
|
Mar
|
Apr
(5) |
May
|
Jun
|
Jul
(11) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Douglas E E. <dee...@gm...> - 2016-07-13 19:20:28
|
<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">On 7/13/2016 5:30 AM, Nguyễn Hồng Quân
wrote:<br>
</div>
<blockquote
cite="mid:CAL...@ma..."
type="cite">
<div dir="ltr">
<div>
<div>
<div>
<div>Hello<br>
<br>
</div>
I'm the maintainer for OpenPGP support in OpenSC.<br>
<br>
</div>
New version v2.1 of OpenPGP comes with support of decryption
with AES key stored in the card. I want to add this feature
to OpenSC, especially PKCS#11. </div>
</div>
</div>
</blockquote>
<br>
Although OpenSC was based on PKCS#11 2.20, there some extensions for
v2.30 and v2.40<br>
OpenSC only supports RSA and EC keys, but internally some cards uses
AES, but only for administrative card uses, not for PKCS#11. <br>
<br>
Start by reading the PKCS#11 2.40 standards. <br>
<a class="moz-txt-link-freetext" href="https://www.oasis-open.org/standards">https://www.oasis-open.org/standards</a><br>
<br>
<a class="moz-txt-link-freetext" href="http://docs.oasis-open.org/pkcs11/pkcs11-base/v2.40/os/pkcs11-base-v2.40-os.pdf">http://docs.oasis-open.org/pkcs11/pkcs11-base/v2.40/os/pkcs11-base-v2.40-os.pdf</a><br>
<a class="moz-txt-link-freetext" href="http://docs.oasis-open.org/pkcs11/pkcs11-curr/v2.40/os/pkcs11-curr-v2.40-os.pdf">http://docs.oasis-open.org/pkcs11/pkcs11-curr/v2.40/os/pkcs11-curr-v2.40-os.pdf</a><br>
There are also some errata to the above. <br>
<br>
<br>
<br>
<blockquote
cite="mid:CAL...@ma..."
type="cite">
<div dir="ltr">
<div>
<div>My questions are:<br>
<br>
</div>
<div>- Can it be added to PKCS#11 code?</div>
</div>
</div>
</blockquote>
<br>
AES mechanisums are defined in PKCS#11. PKCS#11 defines 3 types of
keys, Public, Private and Secret. AES would be a Secret key. <br>
See the pkcs11-curr-v2.40-os above, section 2.8 AES.<br>
<br>
<blockquote
cite="mid:CAL...@ma..."
type="cite">
<div dir="ltr">
<div>
<div> Is C_Decrypt function the right place to do? </div>
</div>
</div>
</blockquote>
<br>
Depends on the AES mechanism your token supports. <br>
<br>
<blockquote
cite="mid:CAL...@ma..."
type="cite">
<div dir="ltr">
<div>
<div>If yes, which PKCS#11 application/tool can be used to
debug and test? </div>
</div>
</div>
</blockquote>
<br>
None that I know of. OpenSC really only deals with RSA and EC keys.
<br>
<br>
<blockquote
cite="mid:CAL...@ma..."
type="cite">
<div dir="ltr">
<div>
<div>Mozilla apps don't let me pick a symmetric key.<br>
</div>
</div>
</div>
</blockquote>
<br>
Mozilla calls PKCS#11 modules to support smart cards. There is no
Secret key smart cards that I know of for them to use. <br>
<br>
<blockquote
cite="mid:CAL...@ma..."
type="cite">
<div dir="ltr">
<div>- Can it be added to pkcs15 tools, the "pkcs15-crypt
--decipher" command, for example?</div>
</div>
</blockquote>
<br>
Not with out a lot more OpenSC programming. <br>
<br>
<blockquote
cite="mid:CAL...@ma..."
type="cite">
<div dir="ltr">
<div> Looking into its source code, I found that the tool only
lookup private keys.<br>
</div>
</div>
</blockquote>
<br>
Yes RSA, GOST and EC are supported by OpenSC. <br>
<br>
Within OpenSC, the closest thing to Secret Key support is with EC
key derivation, a generic secret key is returned, and the minimal
PKCS#11 interface is available to retrieve the secret key value. <br>
<br>
pkcs11-tool.c in derive_key does: <br>
rv = p11->C_DeriveKey(session, &mech, key, newkey_template,
5, &newkey);<br>
The newkey is a secret key and its value is obtained. <br>
<br>
pkcs11-tool.c can show and generate secret_keys. <br>
<br>
src/pkcs11/framework-pkcs15.c has a pkcs15_create_secret_key but its
only used for the generic secret key. <br>
<br>
<blockquote
cite="mid:CAL...@ma..."
type="cite">
<div dir="ltr">
<div><br>
</div>
Regards<br clear="all">
<div>
<div>
<div>
<div>
<div><br>
-- <br>
<div class="gmail_signature"
data-smartmail="gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div><span style="font-family:courier
new,monospace">Quân<br>
</span></div>
<div><span style="font-family:courier
new,monospace">***********************************************<br>
* Nguyễn Hồng Quân
*<br>
* ☎ 093 9030 338
*<br>
* Facebook:
ng.hong.quan
*<br>
</span></div>
<span style="font-family:courier
new,monospace">* 🌏 <a
moz-do-not-send="true"
href="http://quan.hoabinh.vn"
target="_blank">quan.hoabinh.vn</a>
*<br>
</span>
<div><span style="font-family:courier
new,monospace">***********************************************</span></div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Opensc-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Ope...@li...">Ope...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/opensc-devel">https://lists.sourceforge.net/lists/listinfo/opensc-devel</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="200">--
Douglas E. Engert <a class="moz-txt-link-rfc2396E" href="mailto:DEE...@gm..."><DEE...@gm...></a>
</pre>
</body>
</html>
|
|
From: Nguyễn H. Q. <ng....@gm...> - 2016-07-13 10:30:27
|
Hello I'm the maintainer for OpenPGP support in OpenSC. New version v2.1 of OpenPGP comes with support of decryption with AES key stored in the card. I want to add this feature to OpenSC, especially PKCS#11. My questions are: - Can it be added to PKCS#11 code? Is C_Decrypt function the right place to do? If yes, which PKCS#11 application/tool can be used to debug and test? Mozilla apps don't let me pick a symmetric key. - Can it be added to pkcs15 tools, the "pkcs15-crypt --decipher" command, for example? Looking into its source code, I found that the tool only lookup private keys. Regards -- Quân *********************************************** * Nguyễn Hồng Quân * * ☎ 093 9030 338 * * Facebook: ng.hong.quan * * 🌏 quan.hoabinh.vn * *********************************************** |
|
From: Roberto R. <ro...@re...> - 2016-07-05 21:42:07
|
Il 05 luglio 2016 23:10:03 CEST, Douglas E Engert <dee...@gm...> ha scritto: >Looks like that reader has many issues. >Google for pcsclite support acr38u >http://pcsclite.alioth.debian.org/ccid/supported.html >says: "Old versions of this reader are bogus: the reader do timeout >when a special USB frame is sent from the reader. If the frame size is >a multiple of wMaxPacketSize the communication is stopped." > >You say: "but only with an old acr38u reader" >buy a new reader? :-) I agree, definitely. rob |
|
From: Douglas E E. <dee...@gm...> - 2016-07-05 21:10:07
|
<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Looks like that reader has many issues. <br>
Google for pcsclite support acr38u <br>
<a class="moz-txt-link-freetext" href="http://pcsclite.alioth.debian.org/ccid/supported.html">http://pcsclite.alioth.debian.org/ccid/supported.html</a><br>
says: "<span style="color: rgb(0, 0, 0); font-family: arial,
sans-serif; font-size: medium; font-style: normal; font-variant:
normal; font-weight: normal; letter-spacing: normal; line-height:
normal; orphans: auto; text-align: left; text-indent: 0px;
text-transform: none; white-space: normal; widows: 1;
word-spacing: 0px; -webkit-text-stroke-width: 0px; display: inline
!important; float: none; background-color: rgb(255, 0, 255);">Old
versions of this reader are bogus: the reader do timeout when a
special USB frame is sent from the reader. If the frame size is a
multiple of wMaxPacketSize the communication is stopped."<br>
<br>
You say: "</span>but only with an old acr38u reader" <br>
buy a new reader?<br>
<br>
<div class="moz-cite-prefix">On 7/5/2016 1:03 PM, Roberto Resoli
wrote:<br>
</div>
<blockquote cite="mid:577...@re..." type="cite">
<pre wrap="">Hi,
I added the following commento on closed issue #393
<a class="moz-txt-link-freetext" href="https://github.com/OpenSC/OpenSC/issues/393">https://github.com/OpenSC/OpenSC/issues/393</a>
"Hello, it happens that I just received one of these cards. I'm
experiencing the same issue, but only with an old acr38u reader not
supported by libccid (I have to use libacr38u instead). With other two
readers, (including newer acr38u) no issue."
Do you think it's ok to reopen it? I'm able to do some testing and
reporting on it, even if i think it's a reader driver issue.
bye,
rob
------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
<a class="moz-txt-link-freetext" href="http://sdm.link/attshape">http://sdm.link/attshape</a>
_______________________________________________
Opensc-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Ope...@li...">Ope...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/opensc-devel">https://lists.sourceforge.net/lists/listinfo/opensc-devel</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="200">--
Douglas E. Engert <a class="moz-txt-link-rfc2396E" href="mailto:DEE...@gm..."><DEE...@gm...></a>
</pre>
</body>
</html>
|
|
From: Roberto R. <ro...@re...> - 2016-07-05 18:20:13
|
Hi, I added the following commento on closed issue #393 https://github.com/OpenSC/OpenSC/issues/393 "Hello, it happens that I just received one of these cards. I'm experiencing the same issue, but only with an old acr38u reader not supported by libccid (I have to use libacr38u instead). With other two readers, (including newer acr38u) no issue." Do you think it's ok to reopen it? I'm able to do some testing and reporting on it, even if i think it's a reader driver issue. bye, rob |
|
From: Ludovic R. <lud...@gm...> - 2016-07-05 07:44:33
|
Thanks Douglas, I knew I could find PIV experts on this list :-) The token uses the TKSmartCardTokenSession class: https://developer.apple.com/library/prerelease/content/samplecode/PIVToken/Listings/PIVToken_Token_h.html line 46: @interface PIVTokenSession : TKSmartCardTokenSession<TKTokenSessionDelegate> This class manages the exclusive accesses for you: https://developer.apple.com/reference/cryptotokenkit/tksmartcardtokensession/1773453-smartcard?language=objc " Discussion This property can only be accessed in the implementation of a TKTokenSessionDelegate protocol delegate method. *If the associated token has a value set for the AID property, this property opens an exclusive session to the card, with the application already selected.* You should not call beginSessionWithReply: or endSession on the returned value. Instead, *the system will take care of beginning the exclusive session and terminating it* when the current token request servicing is finished. " The AID used by the token is defined in Info.plist file as: <key>com.apple.ctk.aid</key> <string>a000000308 00001000 0100</string> It looks like the CryptoTokenKit API is adapted to PIV like cards. It may be more complex to write a token for other kind of cards. Bye 2016-07-04 21:07 GMT+02:00 Douglas E Engert <dee...@gm...>: > A quick glance at the web page shows they have been reading NIST 800-73-4 and looks like they support most of the 800-73-3 features. > The History object is supported in that as they will read the on-card retired key management certificates. But not off card certificates which have on card keys (as best as I can tell. ) They also > mention ECDH and alwaysAuthenticate for the SIGN_KEY, as per standard. > > They don't need to use some of the other objects, like Printed information, Finger Prints. So no need to have code to read them > (The Microsoft PIV driver does not read them either.) > > They expect the card to have a Card Capability Container object. (Microsoft expects the card to have a CHUID object.) > They and Microsoft use these objects to get the equivalent of a card serial number. > > No support for PKCS#11, pkcs#15 or openssl engine that I can see. Microsoft does not provide these either. > So OpenSC still has a niche to fill if these are important for other applications. > > As they point out: "This sample demonstrates how to write an extension for CryptoTokenKit framework this is an example, which could be used with other smart cards." And as you said, someone might > want to write the equivalent of the windows minidriver to support smartcards other then PIV. > > Its not obvious if or how they handle interference from other smart card middleware running at the same time on the machine. Such as CAC middleware or OpenSC that may change the selected applet or > reset the card, or security state. Also not clear if session or transaction locking is used. > > Just as on Windows, if you stick with PIV cards and the OS vendor's applications or APIs, you would not need OpenSC at all. > > On 7/4/2016 9:25 AM, Ludovic Rousseau wrote: >> Hello, >> >> Apple provides a sample implementation for PIVToken, a token using the >> new API that replaces tokend. >> >> See http://ludovicrousseau.blogspot.fr/2016/07/macos-sierra-and-pivtoken-source-code.html >> >> I guess the "OpenSC project" may want to also provide a token for OpenSC. >> >> I am also interested to know what the PIV experts on this list have to >> say about the sample code provided by Apple. >> >> Bye >> > > -- > > Douglas E. Engert <DEE...@gm...> > > > > ------------------------------------------------------------------------------ > Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San > Francisco, CA to explore cutting-edge tech and listen to tech luminaries > present their vision of the future. This family event has something for > everyone, including kids. Get more information and register today. > http://sdm.link/attshape > _______________________________________________ > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel -- Dr. Ludovic Rousseau |
|
From: Douglas E E. <dee...@gm...> - 2016-07-04 19:08:03
|
A quick glance at the web page shows they have been reading NIST 800-73-4 and looks like they support most of the 800-73-3 features. The History object is supported in that as they will read the on-card retired key management certificates. But not off card certificates which have on card keys (as best as I can tell. ) They also mention ECDH and alwaysAuthenticate for the SIGN_KEY, as per standard. They don't need to use some of the other objects, like Printed information, Finger Prints. So no need to have code to read them (The Microsoft PIV driver does not read them either.) They expect the card to have a Card Capability Container object. (Microsoft expects the card to have a CHUID object.) They and Microsoft use these objects to get the equivalent of a card serial number. No support for PKCS#11, pkcs#15 or openssl engine that I can see. Microsoft does not provide these either. So OpenSC still has a niche to fill if these are important for other applications. As they point out: "This sample demonstrates how to write an extension for CryptoTokenKit framework this is an example, which could be used with other smart cards." And as you said, someone might want to write the equivalent of the windows minidriver to support smartcards other then PIV. Its not obvious if or how they handle interference from other smart card middleware running at the same time on the machine. Such as CAC middleware or OpenSC that may change the selected applet or reset the card, or security state. Also not clear if session or transaction locking is used. Just as on Windows, if you stick with PIV cards and the OS vendor's applications or APIs, you would not need OpenSC at all. On 7/4/2016 9:25 AM, Ludovic Rousseau wrote: > Hello, > > Apple provides a sample implementation for PIVToken, a token using the > new API that replaces tokend. > > See http://ludovicrousseau.blogspot.fr/2016/07/macos-sierra-and-pivtoken-source-code.html > > I guess the "OpenSC project" may want to also provide a token for OpenSC. > > I am also interested to know what the PIV experts on this list have to > say about the sample code provided by Apple. > > Bye > -- Douglas E. Engert <DEE...@gm...> |
|
From: Ludovic R. <lud...@gm...> - 2016-07-04 14:26:16
|
Hello, Apple provides a sample implementation for PIVToken, a token using the new API that replaces tokend. See http://ludovicrousseau.blogspot.fr/2016/07/macos-sierra-and-pivtoken-source-code.html I guess the "OpenSC project" may want to also provide a token for OpenSC. I am also interested to know what the PIV experts on this list have to say about the sample code provided by Apple. Bye -- Dr. Ludovic Rousseau |
|
From: David W. <dw...@in...> - 2016-06-30 10:07:13
|
On Thu, 2016-06-30 at 11:41 +0200, Nikos Mavrogiannopoulos wrote: > On Thu, 2016-06-30 at 09:51 +0200, Ludovic Rousseau wrote: > > > A bug [3] has been opened for Debian: "pam-pkcs11: FTBFS with openssl > > 1.1.0" > > FTBFS is Fails To Build From Source. > > When OpenSSL 1.1.0 will be included in Debian pam-pkcs11 will be > > removed from Debian, unless someone adds support of the new OpenSSL > > API. > > > > If you (or your company) use pam-pkcs11 you should worry about the > > situation. > > > > RedHat provides [4] pam-pkcs11 to its customers. It could be a good > > idea for RedHat to invest some R&D time to take maintenance of the > > software to keep its (paying) customers happy. > > Note that in Red Hat we use pam-pkcs11 with NSS and not openssl. That > option (to my knowledge) seems to work even today. FSVO "seems to work" which I wouldn't necessarily advocate because it doesn't actually comply with that distribution's own packaging guidelines — it doesn't load the correct modules according to the system's PKCS#11 configuration. Hence https://bugzilla.redhat.com/show_bug.cgi?id=1173548 Like many packages in Fedora, we should probably move *away* from NSS unless it gets fixed to comply with the distribution's guidelines. I have a GSoC student working on supporting RFC7512 URIs in NSS this year, but not a lot of progress on loading the correct tokens by default. -- David Woodhouse Open Source Technology Centre Dav...@in... Intel Corporation |
|
From: Ludovic R. <lud...@gm...> - 2016-06-30 07:52:17
|
Hello, PAM PKCS#11 [1] is a Pluggable Authentication Module (PAM) using a PKCS#11 library (smart card, crypto token, etc.). The purpose is to be able to use a smart card to login to a GNU/Linux system. With the introduction of OpenSSL 1.1.0 the API has changed and many software, including pam-pkcs#11, need to be updated to use the new API. For example see [2] for a patch for OpenSC. I am the only maintainer of pam-pkcs11 project. I do not use this software myself any more. I do not have the free time (and motivation) to invest in a code change of pam-pkcs11 to support the new OpenSSL API. If nobody volunteers to do this work then: - pam-pkcs11 will not work with OpenSSL 1.1.0 - pam-pkcs11 will be removed from the GNU/Linux distributions - pam-pkcs11 will not be usable any more. A bug [3] has been opened for Debian: "pam-pkcs11: FTBFS with openssl 1.1.0" FTBFS is Fails To Build From Source. When OpenSSL 1.1.0 will be included in Debian pam-pkcs11 will be removed from Debian, unless someone adds support of the new OpenSSL API. If you (or your company) use pam-pkcs11 you should worry about the situation. RedHat provides [4] pam-pkcs11 to its customers. It could be a good idea for RedHat to invest some R&D time to take maintenance of the software to keep its (paying) customers happy. Regards, [1] https://github.com/OpenSC/pam_pkcs11/wiki [2] https://github.com/OpenSC/OpenSC/pull/749/files [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828487 [4] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Managing_Smart_Cards/enabling-smart-card-login.html -- Dr. Ludovic Rousseau |
|
From: Ludovic R. <lud...@gm...> - 2016-06-27 11:34:39
|
2016-06-27 12:09 GMT+02:00 Niklas Hansel <nik...@ed...>: > Hello, > Hello, > did someone get the Gemalto IDPrime .Net card working with OpenSC? > Here some pcsc_scan information: > > *ATR: 3B 16 96 41 73 74 72 69 64* > *+ TS = 3B --> Direct Convention* > *+ T0 = 16, Y(1): 0001, K: 6 (historical bytes)* > * TA(1) = 96 --> Fi=512, Di=32, 16 cycles/ETU* > * 250000 bits/s at 4 MHz, fMax for Fi = 5 MHz => 312500 bits/s* > *+ Historical bytes: 41 73 74 72 69 64* > * Category indicator byte: 41 (proprietary format)* > > *Possibly identified card (using /usr/share/pcsc/smartcard_list.txt):* > *3B 16 96 41 73 74 72 69 64* > * Gemalto .NET v2.0* > > I'd like to implement a FDE und 2FA with the Card on Linux (CentOS), maybe > someone worked with this card already and has a best practice for me. > You should read http://ludovicrousseau.blogspot.com/2010/04/source-code-of-pkcs11-for-net-cards.html The .Net cards are not supported by OpenSC. But you can use another PKCS#11 library. Bye -- Dr. Ludovic Rousseau |
|
From: Niklas H. <nik...@ed...> - 2016-06-27 10:28:05
|
<font size=2 face="sans-serif">Hello,</font> <br><font size=2 face="sans-serif">did someone get the Gemalto IDPrime .Net card working with OpenSC? </font> <br><font size=2 face="sans-serif">Here some pcsc_scan information:</font> <br> <br><font size=2 face="sans-serif"><i>ATR: 3B 16 96 41 73 74 72 69 64</i></font> <br><font size=2 face="sans-serif"><i>+ TS = 3B --> Direct Convention</i></font> <br><font size=2 face="sans-serif"><i>+ T0 = 16, Y(1): 0001, K: 6 (historical bytes)</i></font> <br><font size=2 face="sans-serif"><i> TA(1) = 96 --> Fi=512, Di=32, 16 cycles/ETU</i></font> <br><font size=2 face="sans-serif"><i> 250000 bits/s at 4 MHz, fMax for Fi = 5 MHz => 312500 bits/s</i></font> <br><font size=2 face="sans-serif"><i>+ Historical bytes: 41 73 74 72 69 64</i></font> <br><font size=2 face="sans-serif"><i> Category indicator byte: 41 (proprietary format)</i></font> <br> <br><font size=2 face="sans-serif"><i>Possibly identified card (using /usr/share/pcsc/smartcard_list.txt):</i></font> <br><font size=2 face="sans-serif"><i>3B 16 96 41 73 74 72 69 64</i></font> <br><font size=2 face="sans-serif"><i> Gemalto .NET v2.0</i></font> <br> <br><font size=2 face="sans-serif">I'd like to implement a FDE und 2FA with the Card on Linux (CentOS), maybe someone worked with this card already and has a best practice for me.</font> <br> <br><font size=2 face="sans-serif">best regards</font> <br><font size=2 face="sans-serif">Niklas</font> <br> <br> <b><font size="2" face="Arial">Die nächsten Messeauftritte </font></b><b><font size="2" face="Arial">der EDAG Group finden Sie unter: </font></b><a href="http://www.edag.de/edag/presse/presseinformationen/veranstaltungen.html"><b><font size="2" face="Arial">http://www.edag.de/edag/presse/presseinformationen/veranstaltungen.html</font></b></a><br> <b><font size="2" face="Arial">The EDAG Group's next exhibitions you will find under:</font></b><b><font size="2" color="#0062E1" face="Arial"> </font></b><b><font size="2" color="#0000FF" face="Arial"><a href="http://www.edag.de/en/edag/press-media/press-information/exhibition-schedule.html">http://www.edag.de/en/edag/press-media/press-information/exhibition-schedule.html</a></font></b><br> <b><i><font size="2" face="Arial"><br> Mehr News und Informationen aus der Welt der EDAG Group können Sie in unserem interaktiven<br> EMAG-Magazin </font></i></b><a href="http://www.edag.de/de/services/corporate-services/newsletter.html"><b><i><font size="2" color="#0000FF" face="Arial">http://www.edag.de/de/services/corporate-services/newsletter.html</font></i></b></a><b><i><font size="2" face="Arial"> nachlesen!</font></i></b><br> <b><i><font size="2" face="Arial">More news and information about the EDAG Group can be found in our interactive EMAG-Magazine</font></i></b><b><i><font size="2" color="#0000FF" face="Arial"> </font></i></b><a href="http://www.edag.de/en/services/corporate-services/newsletter.html"><b><i><font size="2" color="#0000FF" face="Arial">http://www.edag.de/en/services/corporate-services/newsletter.html</font></i></b></a> <br> <font size="2" face="Arial">_________________________________________________________________________________________________________________________<br> Registergericht/Court of jurisdiction: Amtsgericht Wiesbaden, HRB 28257 USt.-Id: DE 292 939 239</font><br> <font size="2" face="Arial">Geschäftsführung / Board of Managing Directors: Jörg Ohlsen (CEO), Harald Poeschke (COO), Jürgen Vogt (CFO)</font><br> <font size="2" face="Arial">Aufsichtsratsvorsitzender / Chairman of the Supervisory Board: Thomas Eichelmann</font><br> <font size="2" face="Arial">Hauptsitz/Headquarters: EDAG Engineering GmbH, Kreuzberger Ring 40, 65205 Wiesbaden Deutschland/Germany / </font><a href="http://www.edag.de"><font size="2" face="Arial">http://www.edag.de</font></a><br> <font size="2" face="Arial">---</font><br> <font size="2" face="Arial">This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden</font><font size="2" face="Arial">.</font> |
|
From: Frank M. <mo...@in...> - 2016-06-26 21:30:31
|
Hi! > I downloaded > https://sourceforge.net/projects/opensc/files/OpenSC/opensc-0.15.0/opensc-0.15.0.tar.gz/download > twice, last year and recently this year, and surprisingly the tarballs > contents are quite different, as well as the file dates: 2015-05-16 and > 2016-02-16. > (I can't compare .zip archives; current still has 2015-05-16 file date, thus > probably stable, but Windows isn't my first priority) Hmm, interesting. Just out of curiosity, could you run `diff` on the extracted directories? You could even compare that with the git commit tagged with 0.15.0... > A binding (for a new driver written as external module in D; as well as the > module acos5_64 itself) renders quite useless for the public if the version > is a moving target. > Problems arise from API differences (called same version 0.15.0) in: > opensc.h (struct sc_reader_driver, struct sc_reader, struct sc_context), > pkcs15.h (struct sc_md_cmap_record, struct sc_md_cardcf, struct sc_md_data, > struct sc_pkcs15_prkey_info), > sc-pkcs11.h (struct sc_pkcs11_config, struct sc_pkcs11_slot). > > Thus I can base on version 0.16.0 only/earliest, which most people's Linux > distributions won't supply for some time (my recent Kubuntu upgrade 16.04 > comes with 0.15.0 whichever)? There are some false assumptions in your thoughts: 1. OpenSC does not install any header files anymore, because we don't want to encourage people to use it! If you use it, nevertheless, you need to cope with the consequences. 2. In the past, the driver loading API has been used to avoid the GPL/LGPL licensing. However, the internal API is not general enough to achieve this and still requires external driver code to be compatible with inclusion in LGPL. I wonder what license your D-driver code has... 3. If you want to support some card with OpenSC we encourage you to contribute the code to the project itself. Here, it will survive all API changes and will get some independent review (hopefully). Regards, Frank. |
|
From: Carsten B. <ka6...@on...> - 2016-06-26 20:22:56
|
Hello folks at OpenSC, I downloaded https://sourceforge.net/projects/opensc/files/OpenSC/opensc-0.15.0/opensc-0.15.0.tar.gz/download twice, last year and recently this year, and surprisingly the tarballs contents are quite different, as well as the file dates: 2015-05-16 and 2016-02-16. (I can't compare .zip archives; current still has 2015-05-16 file date, thus probably stable, but Windows isn't my first priority) A binding (for a new driver written as external module in D; as well as the module acos5_64 itself) renders quite useless for the public if the version is a moving target. Problems arise from API differences (called same version 0.15.0) in: opensc.h (struct sc_reader_driver, struct sc_reader, struct sc_context), pkcs15.h (struct sc_md_cmap_record, struct sc_md_cardcf, struct sc_md_data, struct sc_pkcs15_prkey_info), sc-pkcs11.h (struct sc_pkcs11_config, struct sc_pkcs11_slot). Thus I can base on version 0.16.0 only/earliest, which most people's Linux distributions won't supply for some time (my recent Kubuntu upgrade 16.04 comes with 0.15.0 whichever)? Any ideas? Thanks, Carsten |
|
From: Douglas E E. <dee...@gm...> - 2016-06-25 15:03:32
|
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
OpenSC developers might be interested in this draft doc. <br>
<br>
tokend is not mentioned at all. <br>
PIV is referenced in 7 places, including this vague foot note:<br>
43 The support for PIV card readers on OS X is still evolving<br>
<br>
Not being a Mac OS person, I am just passing it on...<br>
<div class="moz-forward-container"><br>
<br>
-------- Forwarded Message --------
<table class="moz-email-headers-table" border="0" cellpadding="0"
cellspacing="0">
<tbody>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">Subject:
</th>
<td>NIST Released Draft Special Publication 800-179, Guide
to Securing Apple OS X 10.10 Systems for IT Professionals:
A NIST Security Configuration Checklist</td>
</tr>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">Date: </th>
<td>Fri, 24 Jun 2016 20:52:59 -0500</td>
</tr>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">From: </th>
<td>NIST Computer Security Resource Center
<a class="moz-txt-link-rfc2396E" href="mailto:csr...@se..."><csr...@se...></a></td>
</tr>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">Reply-To:
</th>
<td><a class="moz-txt-link-abbreviated" href="mailto:csr...@se...">csr...@se...</a></td>
</tr>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">To: </th>
<td><a class="moz-txt-link-abbreviated" href="mailto:dee...@gm...">dee...@gm...</a></td>
</tr>
</tbody>
</table>
<br>
<br>
<title> NIST Released Draft Special Publication 800-179, Guide to
Securing Apple OS X 10.10 Systems for IT Professionals: A NIST
Security Configuration Checklist
</title>
<p><font face="arial,helvetica,sans-serif" size="3"><strong><span
style="font-family: 'Calibri',sans-serif;">NIST Released
Draft Special Publication 800-179, <em>Guide to Securing
Apple OS X 10.10 Systems for IT Professionals: A NIST
Security Configuration Checklist</em>. This Draft
Special Publication is available for public comment. See
below for further details.</span></strong></font></p>
<p><font face="arial,helvetica,sans-serif" size="3">Information
and links to Draft SP 800-179 can be found on the NIST CSRC
Draft Publications page: <br>
<a class="moz-txt-link-rfc2396E" href="http://csrc.nist.gov/publications/PubsDrafts.html#800-179"><http://csrc.nist.gov/publications/PubsDrafts.html#800-179></a> <br>
*Note: There is a comment template available to use when
submitting comments to this draft document.</font></p>
<p><font face="arial,helvetica,sans-serif" size="3">Deadline to
submit comments: <strong>August 15, 2016</strong></font></p>
<p><font face="arial,helvetica,sans-serif" size="3">Email comments
or questions about this draft document to: <br>
<a class="moz-txt-link-rfc2396E" href="mailto:800...@ni..."><800...@ni...></a></font></p>
<p><font face="arial,helvetica,sans-serif" size="3">__________ <br>
NIST Computer Security Division <br>
<a class="moz-txt-link-abbreviated" href="mailto:web...@ni...">web...@ni...</a> (Attn: Pat O’Reilly)</font></p>
<p><font face="arial,helvetica,sans-serif" size="3"> </font></p>
<div id="mail_footer">
<hr>
<p>Update your subscriptions, modify your password or e-mail
address, or stop subscriptions at any time on your <a
moz-do-not-send="true"
href="http://links.govdelivery.com:80/track?type=click&enid=ZWFzPTEmbWFpbGluZ2lkPTIwMTYwNjI1LjYwNzQzMTkxJm1lc3NhZ2VpZD1NREItUFJELUJVTC0yMDE2MDYyNS42MDc0MzE5MSZkYXRhYmFzZWlkPTEwMDEmc2VyaWFsPTE3MzE4NDIxJmVtYWlsaWQ9ZGVlbmdlcnRAZ21haWwuY29tJnVzZXJpZD1kZWVuZ2VydEBnbWFpbC5jb20mZmw9JmV4dHJhPU11bHRpdmFyaWF0ZUlkPSYmJg==&&&100&&&https://public.govdelivery.com/accounts/USNISTCSRC/subscriber/new">Subscriber
Preferences Page</a>. You will need to use your email
address to log in. If you have questions or problems with the
subscription service, please visit <a moz-do-not-send="true"
href="http://links.govdelivery.com:80/track?type=click&enid=ZWFzPTEmbWFpbGluZ2lkPTIwMTYwNjI1LjYwNzQzMTkxJm1lc3NhZ2VpZD1NREItUFJELUJVTC0yMDE2MDYyNS42MDc0MzE5MSZkYXRhYmFzZWlkPTEwMDEmc2VyaWFsPTE3MzE4NDIxJmVtYWlsaWQ9ZGVlbmdlcnRAZ21haWwuY29tJnVzZXJpZD1kZWVuZ2VydEBnbWFpbC5jb20mZmw9JmV4dHJhPU11bHRpdmFyaWF0ZUlkPSYmJg==&&&101&&&https://subscriberhelp.govdelivery.com/">subscriberhelp.govdelivery.com</a>.
All other enquiries can be directed to <a
moz-do-not-send="true" href="mailto:web...@ni..."><a class="moz-txt-link-abbreviated" href="mailto:web...@ni...">web...@ni...</a></a>.</p>
<p>This service is provided to you at no charge by the National
Institute of Standards and Technology (NIST).</p>
</div>
<div id="tagline">
<p> </p>
<div>
<hr>
</div>
<p> </p>
<table border="0" cellpadding="0" cellspacing="0">
<tbody>
<tr>
<td width="89%">This email was sent to <a class="moz-txt-link-abbreviated" href="mailto:dee...@gm...">dee...@gm...</a>
using GovDelivery, on behalf of: NIST Computer Security
Resource Center · 100 Bureau Drive · Gaithersburg, MD
20899 · (301) 975-6478</td>
<td align="right" width="11%">
<a moz-do-not-send="true"
href="http://links.govdelivery.com:80/track?type=click&enid=ZWFzPTEmbWFpbGluZ2lkPTIwMTYwNjI1LjYwNzQzMTkxJm1lc3NhZ2VpZD1NREItUFJELUJVTC0yMDE2MDYyNS42MDc0MzE5MSZkYXRhYmFzZWlkPTEwMDEmc2VyaWFsPTE3MzE4NDIxJmVtYWlsaWQ9ZGVlbmdlcnRAZ21haWwuY29tJnVzZXJpZD1kZWVuZ2VydEBnbWFpbC5jb20mZmw9JmV4dHJhPU11bHRpdmFyaWF0ZUlkPSYmJg==&&&102&&&http://www.govdelivery.com/portals/powered-by"
target="_blank"><img moz-do-not-send="true"
src="https://service.govdelivery.com/banners/GOVDELIVERY/logo_gd_poweredby.gif"
alt="Powered by GovDelivery" height="35" border="0"
width="115"></a><br>
<br>
</td>
</tr>
</tbody>
</table>
</div>
<img moz-do-not-send="true"
src="http://links.govdelivery.com:80/track?enid=ZWFzPTEmbWFpbGluZ2lkPTIwMTYwNjI1LjYwNzQzMTkxJm1lc3NhZ2VpZD1NREItUFJELUJVTC0yMDE2MDYyNS42MDc0MzE5MSZkYXRhYmFzZWlkPTEwMDEmdHlwZT1vcGVuJnNlcmlhbD0xNzMxODQyMSZlbWFpbGlkPWRlZW5nZXJ0QGdtYWlsLmNvbSZ1c2VyaWQ9ZGVlbmdlcnRAZ21haWwuY29tJmZsPSZleHRyYT1NdWx0aXZhcmlhdGVJZD0mJiY="
style="border-width:0; border-style:hidden;" alt="" height="1"
width="1">
</div>
</body>
</html>
|
|
From: David W. <dw...@in...> - 2016-06-16 11:08:35
|
On Thu, 2016-06-16 at 08:55 +0000, Marx, Peter wrote: > > the ActiveMQ Java Keystore File used to handle the TLS connections > does not only contain the public key / certificate, but also the > private key. > > This holds true for all applications based on Java Secure Socket > Extension(JSSE) . And the password to access the key pair is in the > app's configuration file... > > This drives my requirement to get rid of the keystore files. Maybe I > misunderstood something at the basis - I'm a late adopter of the > crypto stuff. Yes, all that is absolutely correct. You want to move the key storage away from this file-and-password based storage, onto a separate device so that it can be securely protected. The key can be *used* in situ, but it can never be copied away. All that was implicit fairly much by the time you'd put opensc-devel into the To: field of your first email, let alone started composing your actual message :) Everything that anyone has responded has been compatible with that requirement. But there is evidently some miscommunication here... why do you feel you need to restate it? Did you think my suggestion had missed the point, and would not provide this? -- dwmw2 |
|
From: Marx, P. <Pet...@kn...> - 2016-06-16 08:55:54
|
Confirmed by this source: http://www-01.ibm.com/support/knowledgecenter/SSCQGF_7.1.0/com.ibm.IBMDI.doc_7.1/adminguide07.htm%23ToC_102?lang=en-us the ActiveMQ Java Keystore File used to handle the TLS connections does not only contain the public key / certificate, but also the private key. This holds true for all applications based on Java Secure Socket Extension(JSSE) . And the password to access the key pair is in the app's configuration file... This drives my requirement to get rid of the keystore files. Maybe I misunderstood something at the basis - I'm a late adopter of the crypto stuff. -----Original Message----- From: David Woodhouse [mailto:dw...@in...] Sent: Thursday, June 16, 2016 9:46 AM To: Marx, Peter; ope...@li... Subject: [Secure Email] Re: [Opensc-devel] Crypto Chip Support imaginable ? * PGP - S/MIME Signed by an unverified key: 06/16/2016 at 09:45:44 AM On Wed, 2016-06-15 at 13:57 +0000, Marx, Peter wrote: > let's start with the requirements part: > > 1. I want hardware security. Key pair generation shall happen on > device and private key shall not leave the device. Minimum solution > would be to do this with WolfSSL or OpenSSL plus the existing > ATECC108 support. I'll read that as "private key shall not leave the device except in encrypted form". You're allowed to *store* it off-chip, right? As long as it's encrypted such that only the chip can get it back again. (This just simplifies the storage requirements and the API between host and the crypto processor — you no longer need the whole filesystem and PKCS#15 complexity.) > 2a. I want to leverage the UUID existing in the chip to safeguard the > TLS certificate enrollment process towards the PKI, where the UUIDs > are pre-registered. Idea is to prevent illegal hardware copies. This is kind of orthogonal to the precise model used for making keys available via PKCS#11 to the Java apps. But OK. > 2b. TLS client certificate CSR shall be created based on the UUID and > the keypair. Resulting client cert signed by the CA (via SCEP) today > goes into Java Keystore file. CA cert or TLS server cert go into java > truststore file. > The keystore and truststore files plus the cleartext passwords to > access them are configured in ActiveMQ. As this is potentially > unsecure, I had the idea of leveraging the chip a second time by > storing the certs in it and providing a PKCS#11 interface to them, so > that Java applications like AMQ can access them in a transparant way. > Only Java JCE reconfiguration plus a little AMQ tweak would be > necessary. > > Based on these requirements I'm not sure whether storing the certs in > SoftHSM would be beneficial - one could still take away the certs and > use them on another hardware. No. Certificates are public. It's the corresponding private *keys* that need protecting. > I had checked TPM also, but more for safeguarding the boot process and > integrity of the OS. And as a TPM chip is too bulky (28 pins) for our > board, it wasn't an option anyway. > For TLS via Java there is also no option to interfere with the > encryption (at least to my maybe incomplete knowledge), so again no > solution path. Right. A full TPM isn't what you want. I was only referring to the model we use in the openssl TPM engine, and other places, for asking the TPM to 'sign <this> with <this> key'... where the key is an opaque blob, previously encrypted by the TPM itself (using an internal key of its own) and just handed back to us for *storage*. > For something like data encryption before transmitting you have more > options, as you code yourself. There your proposal of "TPM light" > could indeed be an option. Right. All your private keys — that you're currently storing in the Java keystore — can be available through PKCS#11. They're stored on the host side (managed by the PKCS#11 token) in *encrypted* form so the *only* thing you can do with them is pass them to the crypto chip and ask it nicely to perform an operation with them. If I understand your requirements properly, that seems like the simplest path to a solution. Perhaps you don't even need to make your PKCS#11 token store certificates at all — just leave them where they are at the moment. -- dwmw2 * dw...@in... <dw...@in...> * Issuer: StartCom Ltd. - Unverified Knorr-Bremse IT-Services GmbH Sitz: Muenchen Geschaeftsfuehrer: Helmut Draxler (Vorsitzender), Harald Jessen, Harald Schneider Registergericht Muenchen, HR B 167 268 This transmission is intended solely for the addressee and contains confidential information. If you are not the intended recipient, please immediately inform the sender and delete the message and any attachments from your system. Furthermore, please do not copy the message or disclose the contents to anyone unless agreed otherwise. To the extent permitted by law we shall in no way be liable for any damages, whatever their nature, arising out of transmission failures, viruses, external influence, delays and the like. |
|
From: Anders R. <and...@gm...> - 2016-06-16 08:21:29
|
On Jun 16, 2016 9:29 AM, "Marx, Peter" <Pet...@kn...> wrote: > > Hi Alex, > > > > we don’t have a tight resource limit – It’s much more horsepower than e.g. Raspberry. It’s a NXP T1042 CPU, so no chance to leverage the discussed INTEL features. I would consider contacting the linaro organizatiob which works with similar issues for ARM. Anders > > > > Native Java would be preferred, but JNI wrapped C/C++ Code is a 2nd option. > > > > > > Regards > > > > Peter > > > > From: Alexander Gostrer [mailto:ago...@gm...] > Sent: Wednesday, June 15, 2016 9:20 PM > > To: Marx, Peter > Cc: Douglas E Engert; ope...@li... > Subject: Re: [Opensc-devel] Crypto Chip Support imaginable ? > > > > Hi Peter, > > > > From your explanation my understanding is that you are limited with resources (CPU speed, memory, etc). Did you consider using C/C++ rather than Java? > > > > Regards, > > Alex. > > > > On Wed, Jun 15, 2016 at 9:37 AM, Marx, Peter <Pet...@kn...> wrote: > > Hi Alex, > > > > I’m aware of this engine, see requirement #1. That indeed can cover the provisioning process, combined with certmonger’s getcert via SCEP -> EJBCA PKI solution. > > But the Java apps are not aware of this store, as they expect to access the store via PKCS#11… > > > > Thanks > > > > Peter > > > > > > Knorr-Bremse IT-Services GmbH > Sitz: München > Geschäftsführer: Helmut Draxler (Vorsitzender), Harald Jessen, Harald Schneider > Registergericht München, HR B 167 268 > > This transmission is intended solely for the addressee and contains confidential information. > If you are not the intended recipient, please immediately inform the sender and delete the message and any attachments from your system. > Furthermore, please do not copy the message or disclose the contents to anyone unless agreed otherwise. To the extent permitted by law we shall in no way be liable for any damages, whatever their nature, arising out of transmission failures, viruses, external influence, delays and the like. > > ------------------------------------------------------------------------------ > What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic > patterns at an interface-level. Reveals which users, apps, and protocols are > consuming the most bandwidth. Provides multi-vendor support for NetFlow, > J-Flow, sFlow and other flows. Make informed decisions using capacity planning > reports. http://pubads.g.doubleclick.net/gampad/clk?id=1444514421&iu=/41014381 > _______________________________________________ > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel > |
|
From: David W. <dw...@in...> - 2016-06-16 07:45:54
|
On Wed, 2016-06-15 at 13:57 +0000, Marx, Peter wrote: > let's start with the requirements part: > > 1. I want hardware security. Key pair generation shall happen on > device and private key shall not leave the device. Minimum solution > would be to do this with WolfSSL or OpenSSL plus the existing > ATECC108 support. I'll read that as "private key shall not leave the device except in encrypted form". You're allowed to *store* it off-chip, right? As long as it's encrypted such that only the chip can get it back again. (This just simplifies the storage requirements and the API between host and the crypto processor — you no longer need the whole filesystem and PKCS#15 complexity.) > 2a. I want to leverage the UUID existing in the chip to safeguard the > TLS certificate enrollment process towards the PKI, where the UUIDs > are pre-registered. Idea is to prevent illegal hardware copies. This is kind of orthogonal to the precise model used for making keys available via PKCS#11 to the Java apps. But OK. > 2b. TLS client certificate CSR shall be created based on the UUID and > the keypair. Resulting client cert signed by the CA (via SCEP) today > goes into Java Keystore file. CA cert or TLS server cert go into java > truststore file. > The keystore and truststore files plus the cleartext passwords to > access them are configured in ActiveMQ. As this is potentially > unsecure, I had the idea of leveraging the chip a second time by > storing the certs in it and > providing a PKCS#11 interface to them, so that Java applications like > AMQ can access them in a transparant way. Only Java JCE > reconfiguration plus a little AMQ tweak would be necessary. > > Based on these requirements I'm not sure whether storing the certs in > SoftHSM would be beneficial - one could still take away the certs and > use them on another hardware. No. Certificates are public. It's the corresponding private *keys* that need protecting. > I had checked TPM also, but more for safeguarding the boot process > and integrity of the OS. And as a TPM chip is too bulky (28 pins) for > our board, it wasn't an option anyway. > For TLS via Java there is also no option to interfere with the > encryption (at least to my maybe incomplete knowledge), so again no > solution path. Right. A full TPM isn't what you want. I was only referring to the model we use in the openssl TPM engine, and other places, for asking the TPM to 'sign <this> with <this> key'... where the key is an opaque blob, previously encrypted by the TPM itself (using an internal key of its own) and just handed back to us for *storage*. > For something like data encryption before transmitting you have more > options, as you code yourself. There your proposal of "TPM light" > could indeed be an option. Right. All your private keys — that you're currently storing in the Java keystore — can be available through PKCS#11. They're stored on the host side (managed by the PKCS#11 token) in *encrypted* form so the *only* thing you can do with them is pass them to the crypto chip and ask it nicely to perform an operation with them. If I understand your requirements properly, that seems like the simplest path to a solution. Perhaps you don't even need to make your PKCS#11 token store certificates at all — just leave them where they are at the moment. -- dwmw2 |
|
From: Marx, P. <Pet...@kn...> - 2016-06-16 07:27:37
|
Hi Alex, we don’t have a tight resource limit – It’s much more horsepower than e.g. Raspberry. It’s a NXP T1042 CPU, so no chance to leverage the discussed INTEL features. Native Java would be preferred, but JNI wrapped C/C++ Code is a 2nd option. Regards Peter From: Alexander Gostrer [mailto:ago...@gm...] Sent: Wednesday, June 15, 2016 9:20 PM To: Marx, Peter Cc: Douglas E Engert; ope...@li... Subject: Re: [Opensc-devel] Crypto Chip Support imaginable ? Hi Peter, From your explanation my understanding is that you are limited with resources (CPU speed, memory, etc). Did you consider using C/C++ rather than Java? Regards, Alex. On Wed, Jun 15, 2016 at 9:37 AM, Marx, Peter <Pet...@kn...<mailto:Pet...@kn...>> wrote: Hi Alex, I’m aware of this engine, see requirement #1. That indeed can cover the provisioning process, combined with certmonger’s getcert via SCEP -> EJBCA PKI solution. But the Java apps are not aware of this store, as they expect to access the store via PKCS#11… Thanks Peter Knorr-Bremse IT-Services GmbH Sitz: Muenchen Geschaeftsfuehrer: Helmut Draxler (Vorsitzender), Harald Jessen, Harald Schneider Registergericht Muenchen, HR B 167 268 This transmission is intended solely for the addressee and contains confidential information. If you are not the intended recipient, please immediately inform the sender and delete the message and any attachments from your system. Furthermore, please do not copy the message or disclose the contents to anyone unless agreed otherwise. To the extent permitted by law we shall in no way be liable for any damages, whatever their nature, arising out of transmission failures, viruses, external influence, delays and the like. |
|
From: David W. <dw...@in...> - 2016-06-15 20:27:13
|
On Wed, 2016-06-15 at 22:14 +0200, Anders Rundgren wrote: > On 2016-06-15 21:03, David Woodhouse wrote: > > On Wed, 2016-06-15 at 15:24 +0200, Anders Rundgren wrote: > >> > >> Since Intel have firmware in their CPUs it seems that Intel is the > >> party that should enable this capability... > > > > Intel has SGX, which theoretically allows you do do basically the same > > thing as I described to Peter, purely in a software enclave. > > https://software.intel.com/en-us/articles/providing-hardware-based-security-by-leveraging-intel-identity-protection-technology-and > > "To obtain a copy of the IntelJCE you need to contact your Intel representative" One windmill at a time... -- dwmw2 |
|
From: Anders R. <and...@gm...> - 2016-06-15 20:14:17
|
On 2016-06-15 21:03, David Woodhouse wrote: > On Wed, 2016-06-15 at 15:24 +0200, Anders Rundgren wrote: >> >> Since Intel have firmware in their CPUs it seems that Intel is the >> party that should enable this capability... > > Intel has SGX, which theoretically allows you do do basically the same > thing as I described to Peter, purely in a software enclave. https://software.intel.com/en-us/articles/providing-hardware-based-security-by-leveraging-intel-identity-protection-technology-and "To obtain a copy of the IntelJCE you need to contact your Intel representative" Anders > > You could just store your keys in a PKCS#11 token and your keys would > be magically bound to the hardware to prevent copying them, in exactly > the same way. > > If only there was someone from Intel who was interested in that use > case. Of course, even while they were tilting at windmills internally > to fix the SGX signing model and make it possible to ship open source > code to use such an enclave in a PKCS#11 token, they'd probably have > their work cut out making PKCS#11 a first-class citizen in the open > source world so that it's *feasible* to just use a key from PKCS#11 > instead of a filename, for various applications and crypto libraries. > > https://fedoraproject.org/wiki/PackageMaintainers/PKCS11 > https://bugzilla.gnome.org/show_bug.cgi?id=679860 > https://bugzilla.gnome.org/show_bug.cgi?id=719982 > ...etc... > |
|
From: Alexander G. <ago...@gm...> - 2016-06-15 19:20:12
|
Hi Peter, >From your explanation my understanding is that you are limited with resources (CPU speed, memory, etc). Did you consider using C/C++ rather than Java? Regards, Alex. On Wed, Jun 15, 2016 at 9:37 AM, Marx, Peter <Pet...@kn...> wrote: > Hi Alex, > > > > I’m aware of this engine, see requirement #1. That indeed can cover the > provisioning process, combined with certmonger’s getcert via SCEP -> EJBCA > PKI solution. > > But the Java apps are not aware of this store, as they expect to access > the store via PKCS#11… > > > > Thanks > > > > Peter > > > > > > *From:* Alexander Gostrer [mailto:ago...@gm...] > *Sent:* Wednesday, June 15, 2016 5:44 PM > *To:* Marx, Peter > *Cc:* Douglas E Engert; ope...@li... > *Subject:* Re: [Opensc-devel] Crypto Chip Support imaginable ? > > > > Hi Peter, > > > > Here is the OpenSSL Engine that we wrote by the Atmel request: > https://github.com/AtmelCSO/cryptoauth-openssl-engine. It supports > ATECC508A that is a superset of ATECC108 (has Diffie-Hellman). The engine > also supports keeping certificates on the ATECC508A hardware. Like Douglas > and David already said, it will not add any protection. But it is > implemented. Youy can use it. > > > > We do not use OpenCS in this project: we found that we didn't need any > http support. Let me know if you want to talk to Atmel's FAE: they are very > responsive and knowledgeable. > > > > Regards, > > Alex > > > > On Wed, Jun 15, 2016 at 7:29 AM, Marx, Peter <Pet...@kn...> > wrote: > > good point. Hopefully we can limit the enrollment to a trusted > subcontractor's network. As the UUIDs resemble a known set which is relayed > from ATMEL to us before the chips are soldered onto the boards, > only "spoofing" UUIDs out of this set would be the final attack vector I > can't mitigate. > > -----Original Message----- > From: Douglas E Engert [mailto:dee...@gm...] > Sent: Wednesday, June 15, 2016 4:20 PM > To: ope...@li... > Subject: Re: [Opensc-devel] Crypto Chip Support imaginable ? > > > > On 6/15/2016 8:57 AM, Marx, Peter wrote: > > let's start with the requirements part: > > > > 1. I want hardware security. Key pair generation shall happen on device > and private key shall not leave the device. Minimum solution would be to do > this with WolfSSL or OpenSSL plus the existing ATECC108 support. > > > > 2a. I want to leverage the UUID existing in the chip to safeguard the > TLS certificate enrollment process towards the PKI, where the UUIDs are > pre-registered. Idea is to prevent illegal hardware copies. > > > > 2b. TLS client certificate CSR shall be created based on the UUID and > the keypair. Resulting client cert signed by the CA (via SCEP) today goes > into Java Keystore file. CA cert or TLS server cert go into java truststore > file. > > The keystore and truststore files plus the cleartext passwords to > > access them are configured in ActiveMQ. As this is potentially unsecure, > I had the idea of leveraging the chip a second time by storing the certs in > it and providing a PKCS#11 interface to them, so that Java applications > like AMQ can access them in a transparant way. Only Java JCE > reconfiguration plus a little AMQ tweak would be necessary. > > > > Based on these requirements I'm not sure whether storing the certs in > SoftHSM would be beneficial - one could still take away the certs and use > them on another hardware. > > But the public key in the cert only works with the private key in the > device. Copying the certs should not work. > This security depends on the CA only signing a CSR with the UUID from the > chip. That is not clear how the CA verifies the UUID is the one on the > chip. This is a card management issue for the CA. If the CA is only > signing CSRs generated at you factory where you have physical control of > the chip, then it could work. If the CSR is generated by the user or in the > field, the CA may not be able to validate the UUID is from the chip that > signed the CSR. > > > > > I had checked TPM also, but more for safeguarding the boot process and > integrity of the OS. And as a TPM chip is too bulky (28 pins) for our > board, it wasn't an option anyway. > > For TLS via Java there is also no option to interfere with the > encryption (at least to my maybe incomplete knowledge), so again no > solution path. > > > > For something like data encryption before transmitting you have more > options, as you code yourself. There your proposal of "TPM light" could > indeed be an option. > > > > Peter > > > > > > -----Original Message----- > > From: David Woodhouse [mailto:dw...@in...] > > Sent: Tuesday, June 14, 2016 1:12 PM > > To: Marx, Peter; ope...@li... > > Subject: Re: [Opensc-devel] Crypto Chip Support imaginable ? > > > > * PGP - S/MIME Signed by an unverified key: 06/14/2016 at 01:11:58 PM > > > > On Tue, 2016-06-14 at 09:42 +0000, Marx, Peter wrote: > >> I’m IT architect in a big IoT project. I’m looking for getting > >> PKCS#11 support for Java applications on Linux, so i can get rid of > >> the keystore files of e.g. Apache ActiveMQ. TLS certificates and keys > >> shall be created/stored in hardware instead. > >> > >> But I can’t use Smartcards. The idea is to use a cryptochip on the > >> mainboard (headless Linux field unit) like the ATMEL ATECC108A. The > >> chip is on I2C bus and is e.g. accessible from Linux as a device. > > OK... first question: why do you want certificates in hardware? What's > the point in that? > > > > Is there some kind of design requirement where you want to be able to > wipe and re-image the operating system storage, but leave the > > *certificates* in the store intact? And even if it's that, isn't it > easier to just have separate storage for the certificates? > > > > Here's a straw man proposal; tell me why/if it doesn't work for you. > > > > Take an existing software PKCS#11 token, like SoftHSM or the NSS softokn > (which is entirely usable outside NSS; I was using it with wpa_supplicant > only a few hours ago). That's your certificate storage. > > > > For keys though, this doesn't work — I assume you're here because you > really *do* want hardware security so that the private key can't be copied > away from the device; only used in situ. > > > > For this, the TPM model works. Not the whole complex TSS stack, but just > the basic concept — you store your private keys in software, but > *encrypted*. With a key that only exists inside the hardware (and is fairly > much the *only* thing the hardware stores). > > > > So when you want to perform an encrypt/decrypt/sign/verify operation > with a given key, you hand the encrypted key to the Atmel µc and ask > > *it* to decrypt the key and then perform the operation. Optionally, it > can demand a PIN when you do so. > > > > I'm not sure how well that would fit into OpenSC, but it does seem like > the low-effort way to achieving (what I assume to be) your requirements. > > > > -- > > Douglas E. Engert <DEE...@gm...> > > > > > ------------------------------------------------------------------------------ > What NetFlow Analyzer can do for you? Monitors network bandwidth and > traffic > patterns at an interface-level. Reveals which users, apps, and protocols > are > consuming the most bandwidth. Provides multi-vendor support for NetFlow, > J-Flow, sFlow and other flows. Make informed decisions using capacity > planning > reports. > http://pubads.g.doubleclick.net/gampad/clk?id=1444514421&iu=/41014381 > _______________________________________________ > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel > > Knorr-Bremse IT-Services GmbH > Sitz: Muenchen > Geschaeftsfuehrer: Helmut Draxler (Vorsitzender), Harald Jessen, Harald > Schneider > Registergericht Muenchen, HR B 167 268 > > This transmission is intended solely for the addressee and contains > confidential information. > If you are not the intended recipient, please immediately inform the > sender and delete the message and any attachments from your system. > Furthermore, please do not copy the message or disclose the contents to > anyone unless agreed otherwise. To the extent permitted by law we shall in > no way be liable for any damages, whatever their nature, arising out of > transmission failures, viruses, external influence, delays and the like. > > ------------------------------------------------------------------------------ > What NetFlow Analyzer can do for you? Monitors network bandwidth and > traffic > patterns at an interface-level. Reveals which users, apps, and protocols > are > consuming the most bandwidth. Provides multi-vendor support for NetFlow, > J-Flow, sFlow and other flows. Make informed decisions using capacity > planning > reports. > http://pubads.g.doubleclick.net/gampad/clk?id=1444514421&iu=/41014381 > _______________________________________________ > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel > > > > > Knorr-Bremse IT-Services GmbH > Sitz: München > Geschäftsführer: Helmut Draxler (Vorsitzender), Harald Jessen, Harald > Schneider > Registergericht München, HR B 167 268 > > This transmission is intended solely for the addressee and contains > confidential information. > If you are not the intended recipient, please immediately inform the > sender and delete the message and any attachments from your system. > Furthermore, please do not copy the message or disclose the contents to > anyone unless agreed otherwise. To the extent permitted by law we shall in > no way be liable for any damages, whatever their nature, arising out of > transmission failures, viruses, external influence, delays and the like. > |
|
From: David W. <dw...@in...> - 2016-06-15 19:04:10
|
On Wed, 2016-06-15 at 15:24 +0200, Anders Rundgren wrote: > > Since Intel have firmware in their CPUs it seems that Intel is the > party that should enable this capability... Intel has SGX, which theoretically allows you do do basically the same thing as I described to Peter, purely in a software enclave. You could just store your keys in a PKCS#11 token and your keys would be magically bound to the hardware to prevent copying them, in exactly the same way. If only there was someone from Intel who was interested in that use case. Of course, even while they were tilting at windmills internally to fix the SGX signing model and make it possible to ship open source code to use such an enclave in a PKCS#11 token, they'd probably have their work cut out making PKCS#11 a first-class citizen in the open source world so that it's *feasible* to just use a key from PKCS#11 instead of a filename, for various applications and crypto libraries. https://fedoraproject.org/wiki/PackageMaintainers/PKCS11 https://bugzilla.gnome.org/show_bug.cgi?id=679860 https://bugzilla.gnome.org/show_bug.cgi?id=719982 ...etc... -- dwmw2 |
|
From: Marx, P. <Pet...@kn...> - 2016-06-15 16:37:25
|
Hi Alex, I’m aware of this engine, see requirement #1. That indeed can cover the provisioning process, combined with certmonger’s getcert via SCEP -> EJBCA PKI solution. But the Java apps are not aware of this store, as they expect to access the store via PKCS#11… Thanks Peter From: Alexander Gostrer [mailto:ago...@gm...] Sent: Wednesday, June 15, 2016 5:44 PM To: Marx, Peter Cc: Douglas E Engert; ope...@li... Subject: Re: [Opensc-devel] Crypto Chip Support imaginable ? Hi Peter, Here is the OpenSSL Engine that we wrote by the Atmel request: https://github.com/AtmelCSO/cryptoauth-openssl-engine. It supports ATECC508A that is a superset of ATECC108 (has Diffie-Hellman). The engine also supports keeping certificates on the ATECC508A hardware. Like Douglas and David already said, it will not add any protection. But it is implemented. Youy can use it. We do not use OpenCS in this project: we found that we didn't need any http support. Let me know if you want to talk to Atmel's FAE: they are very responsive and knowledgeable. Regards, Alex On Wed, Jun 15, 2016 at 7:29 AM, Marx, Peter <Pet...@kn...<mailto:Pet...@kn...>> wrote: good point. Hopefully we can limit the enrollment to a trusted subcontractor's network. As the UUIDs resemble a known set which is relayed from ATMEL to us before the chips are soldered onto the boards, only "spoofing" UUIDs out of this set would be the final attack vector I can't mitigate. -----Original Message----- From: Douglas E Engert [mailto:dee...@gm...<mailto:dee...@gm...>] Sent: Wednesday, June 15, 2016 4:20 PM To: ope...@li...<mailto:ope...@li...> Subject: Re: [Opensc-devel] Crypto Chip Support imaginable ? On 6/15/2016 8:57 AM, Marx, Peter wrote: > let's start with the requirements part: > > 1. I want hardware security. Key pair generation shall happen on device and private key shall not leave the device. Minimum solution would be to do this with WolfSSL or OpenSSL plus the existing ATECC108 support. > > 2a. I want to leverage the UUID existing in the chip to safeguard the TLS certificate enrollment process towards the PKI, where the UUIDs are pre-registered. Idea is to prevent illegal hardware copies. > > 2b. TLS client certificate CSR shall be created based on the UUID and the keypair. Resulting client cert signed by the CA (via SCEP) today goes into Java Keystore file. CA cert or TLS server cert go into java truststore file. > The keystore and truststore files plus the cleartext passwords to > access them are configured in ActiveMQ. As this is potentially unsecure, I had the idea of leveraging the chip a second time by storing the certs in it and providing a PKCS#11 interface to them, so that Java applications like AMQ can access them in a transparant way. Only Java JCE reconfiguration plus a little AMQ tweak would be necessary. > > Based on these requirements I'm not sure whether storing the certs in SoftHSM would be beneficial - one could still take away the certs and use them on another hardware. But the public key in the cert only works with the private key in the device. Copying the certs should not work. This security depends on the CA only signing a CSR with the UUID from the chip. That is not clear how the CA verifies the UUID is the one on the chip. This is a card management issue for the CA. If the CA is only signing CSRs generated at you factory where you have physical control of the chip, then it could work. If the CSR is generated by the user or in the field, the CA may not be able to validate the UUID is from the chip that signed the CSR. > > I had checked TPM also, but more for safeguarding the boot process and integrity of the OS. And as a TPM chip is too bulky (28 pins) for our board, it wasn't an option anyway. > For TLS via Java there is also no option to interfere with the encryption (at least to my maybe incomplete knowledge), so again no solution path. > > For something like data encryption before transmitting you have more options, as you code yourself. There your proposal of "TPM light" could indeed be an option. > > Peter > > > -----Original Message----- > From: David Woodhouse [mailto:dw...@in...<mailto:dw...@in...>] > Sent: Tuesday, June 14, 2016 1:12 PM > To: Marx, Peter; ope...@li...<mailto:ope...@li...> > Subject: Re: [Opensc-devel] Crypto Chip Support imaginable ? > > * PGP - S/MIME Signed by an unverified key: 06/14/2016 at 01:11:58 PM > > On Tue, 2016-06-14 at 09:42 +0000, Marx, Peter wrote: >> I’m IT architect in a big IoT project. I’m looking for getting >> PKCS#11 support for Java applications on Linux, so i can get rid of >> the keystore files of e.g. Apache ActiveMQ. TLS certificates and keys >> shall be created/stored in hardware instead. >> >> But I can’t use Smartcards. The idea is to use a cryptochip on the >> mainboard (headless Linux field unit) like the ATMEL ATECC108A. The >> chip is on I2C bus and is e.g. accessible from Linux as a device. > OK... first question: why do you want certificates in hardware? What's the point in that? > > Is there some kind of design requirement where you want to be able to wipe and re-image the operating system storage, but leave the > *certificates* in the store intact? And even if it's that, isn't it easier to just have separate storage for the certificates? > > Here's a straw man proposal; tell me why/if it doesn't work for you. > > Take an existing software PKCS#11 token, like SoftHSM or the NSS softokn (which is entirely usable outside NSS; I was using it with wpa_supplicant only a few hours ago). That's your certificate storage. > > For keys though, this doesn't work — I assume you're here because you really *do* want hardware security so that the private key can't be copied away from the device; only used in situ. > > For this, the TPM model works. Not the whole complex TSS stack, but just the basic concept — you store your private keys in software, but *encrypted*. With a key that only exists inside the hardware (and is fairly much the *only* thing the hardware stores). > > So when you want to perform an encrypt/decrypt/sign/verify operation with a given key, you hand the encrypted key to the Atmel µc and ask > *it* to decrypt the key and then perform the operation. Optionally, it can demand a PIN when you do so. > > I'm not sure how well that would fit into OpenSC, but it does seem like the low-effort way to achieving (what I assume to be) your requirements. > -- Douglas E. Engert <DEE...@gm...<mailto:DEE...@gm...>> ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. http://pubads.g.doubleclick.net/gampad/clk?id=1444514421&iu=/41014381 _______________________________________________ Opensc-devel mailing list Ope...@li...<mailto:Ope...@li...> https://lists.sourceforge.net/lists/listinfo/opensc-devel Knorr-Bremse IT-Services GmbH Sitz: Muenchen Geschaeftsfuehrer: Helmut Draxler (Vorsitzender), Harald Jessen, Harald Schneider Registergericht Muenchen, HR B 167 268 This transmission is intended solely for the addressee and contains confidential information. If you are not the intended recipient, please immediately inform the sender and delete the message and any attachments from your system. Furthermore, please do not copy the message or disclose the contents to anyone unless agreed otherwise. To the extent permitted by law we shall in no way be liable for any damages, whatever their nature, arising out of transmission failures, viruses, external influence, delays and the like. ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. http://pubads.g.doubleclick.net/gampad/clk?id=1444514421&iu=/41014381 _______________________________________________ Opensc-devel mailing list Ope...@li...<mailto:Ope...@li...> https://lists.sourceforge.net/lists/listinfo/opensc-devel Knorr-Bremse IT-Services GmbH Sitz: Muenchen Geschaeftsfuehrer: Helmut Draxler (Vorsitzender), Harald Jessen, Harald Schneider Registergericht Muenchen, HR B 167 268 This transmission is intended solely for the addressee and contains confidential information. If you are not the intended recipient, please immediately inform the sender and delete the message and any attachments from your system. Furthermore, please do not copy the message or disclose the contents to anyone unless agreed otherwise. To the extent permitted by law we shall in no way be liable for any damages, whatever their nature, arising out of transmission failures, viruses, external influence, delays and the like. |
5 messages has been excluded from this view by a project administrator.
![https://service.govdelivery.com/banners/GOVDELIVERY/logo_gd_poweredby.gif"](https://service.govdelivery.com/banners/GOVDELIVERY/logo_gd_poweredby.gif"){kind=link}