[gentoo-nfp] Developer Crypto Hardware (AGM)

[gentoo-nfp] Developer Crypto Hardware (AGM)

[Aaron Bauman]

[-- Attachment #1: Type: text/plain, Size: 3095 bytes --]

Gentoo-bug: https://bugs.gentoo.org/659620

All, this email will serve as a comparison between the two vendors which
have provided quotes to the Foundation. This does not include Alice's
proposal as U2FZero is currently out of stock in the United States and
does not seem to offer any availability in Asia. Alice did suggest that
we split vendors across geographical markets, but I find this will make
the situation become very difficult to handle. It would also put the
burden on individuals to receive and disperse the tokens and increase
shipping costs, burden the treasurer for reimbursements to be processed,
and possibly cause delays.
 
Yubikey:

Quote received for (150) Yubikey FIPS tokens.

Unit Price: $44.16 USD
Total: $6,624 USD
Discount: 4% (already available to anyone ordering in bulk)

Shipping costs can be found at [1] and the lowest cost projections
given. They do not offer any standard costs for shipping and cannot
discount it.

Open source: Several products are no longer open sourced and tracking
which is/is not can be difficult [4].
 
Nitrokey:
 
Quote received based on (150) Nitrokey Pro tokens.

Unit Price: 27,59 € ($31.58 USD at the time of this email)
Total: 4,138.50 € ($4737.06 USD at the time of this email)
Discount: 33% (With sponsorship agreement on gentoo.org)
 
All prices are already inclusive of VAT.

Shipping times can be found here [2]. Shipping costs can be found here
[3]. The most expensive shipping is worldwide starting at 7,40 €
($8.47 USD at the the time of this email).

Nitrokey has also offered several unique options for Gentoo. They will
provide a custom portal which allows each developer to request their
security token. This is done via a Foundation (infra really) provided
list of valid gentoo.org email addresses. Additionally, they will
provide monthly billing of all purchased devices and the Foundation is
not obligated to purchase all (150) tokens. This can be a standing
agreement until the Foundation decides to remove financial support.
 
Considering both vendors, we can estimate shipping at the highest cost
in order to best prepare for potential expenses.
 
Open source: All products are considered open [4].
 
-----
 
Motion: I move that the board vote to accept the offer from Yubico or
Nitrokey and begin our agreement with the accepted vendor beginning 1
September 2018. This motion will provide security tokens to all current
developers listed in Gentoo's LDAP infrastructure as of 31 August 2018.

Motion: I move that the board vote to maintain the aforementioned
agreement in order to support future Gentoo developers with security
tokens. This motion includes the right to terminate future purchases
based on the Foundation's financials.
 
[1]: https://www.yubico.com/support/shipping-and-buying-information/
[2]: https://www.nitrokey.com/documentation/frequently-asked-questions#how-long-does-the-shipping-take
[3]: https://shop.nitrokey.com/shop/product/nitrokey-pro-2-3
[4]: https://old.lwn.net/Articles/736231/
 
-- 
Cheers,
Aaron

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-nfp] Developer Crypto Hardware (AGM)

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 2895 bytes --]

Hi!

On Sun, 19 Aug 2018 14:42:23 -0400 Aaron Bauman wrote:
> Gentoo-bug: https://bugs.gentoo.org/659620
> 
> All, this email will serve as a comparison between the two vendors which
> have provided quotes to the Foundation. This does not include Alice's
> proposal as U2FZero is currently out of stock in the United States and
> does not seem to offer any availability in Asia. Alice did suggest that
> we split vendors across geographical markets, but I find this will make
> the situation become very difficult to handle. It would also put the
> burden on individuals to receive and disperse the tokens and increase
> shipping costs, burden the treasurer for reimbursements to be processed,
> and possibly cause delays.
>  
> Yubikey:
> 
> Quote received for (150) Yubikey FIPS tokens.
> 
> Unit Price: $44.16 USD
> Total: $6,624 USD
> Discount: 4% (already available to anyone ordering in bulk)
> 
> Shipping costs can be found at [1] and the lowest cost projections
> given. They do not offer any standard costs for shipping and cannot
> discount it.
> 
> Open source: Several products are no longer open sourced and tracking
> which is/is not can be difficult [4].
>  
> Nitrokey:
>  
> Quote received based on (150) Nitrokey Pro tokens.
> 
> Unit Price: 27,59 € ($31.58 USD at the time of this email)
> Total: 4,138.50 € ($4737.06 USD at the time of this email)
> Discount: 33% (With sponsorship agreement on gentoo.org)
>  
> All prices are already inclusive of VAT.
> 
> Shipping times can be found here [2]. Shipping costs can be found here
> [3]. The most expensive shipping is worldwide starting at 7,40 €
> ($8.47 USD at the the time of this email).
> 
> Nitrokey has also offered several unique options for Gentoo. They will
> provide a custom portal which allows each developer to request their
> security token. This is done via a Foundation (infra really) provided
> list of valid gentoo.org email addresses. Additionally, they will
> provide monthly billing of all purchased devices and the Foundation is
> not obligated to purchase all (150) tokens. This can be a standing
> agreement until the Foundation decides to remove financial support.
>  
> Considering both vendors, we can estimate shipping at the highest cost
> in order to best prepare for potential expenses.
>  
> Open source: All products are considered open [4].

1. Are they open hardware? At the very least chip and board
schematics should be available. At best they should be reproducible
by third parties. 

2. How token integrity is protected during shipment?

Otherwise all this security enhancement will be marginal at best if
not fake, since if device is tampered with physically or on design
level, it provides no additional security, only a dangerous false
sense of such security enhancement.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-nfp] Developer Crypto Hardware (AGM)

[Aaron Bauman]

[-- Attachment #1: Type: text/plain, Size: 834 bytes --]

On Sun, Aug 19, 2018 at 09:57:16PM +0300, Andrew Savchenko wrote:
> Hi!
> 

[snip]

> 1. Are they open hardware? At the very least chip and board
> schematics should be available. At best they should be reproducible
> by third parties. 
> 

Please see the link at [1]


> 2. How token integrity is protected during shipment?
> 
> Otherwise all this security enhancement will be marginal at best if
> not fake, since if device is tampered with physically or on design
> level, it provides no additional security, only a dangerous false
> sense of such security enhancement.
> 

All keys are shipped directly from the manufacturer, but I am not aware
of anyway to garauntee the supply chain.

> Best regards,
> Andrew Savchenko

[1]: https://github.com/Nitrokey/nitrokey-pro-hardware

-- 
Cheers,
Aaron

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-nfp] Developer Crypto Hardware (AGM)

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 3954 bytes --]

On Sun, 2018-08-19 at 14:42 -0400, Aaron Bauman wrote:
> Gentoo-bug: https://bugs.gentoo.org/659620
> 
> All, this email will serve as a comparison between the two vendors which
> have provided quotes to the Foundation. This does not include Alice's
> proposal as U2FZero is currently out of stock in the United States and
> does not seem to offer any availability in Asia. Alice did suggest that
> we split vendors across geographical markets, but I find this will make
> the situation become very difficult to handle. It would also put the
> burden on individuals to receive and disperse the tokens and increase
> shipping costs, burden the treasurer for reimbursements to be processed,
> and possibly cause delays.
>  
> Yubikey:
> 
> Quote received for (150) Yubikey FIPS tokens.
> 
> Unit Price: $44.16 USD
> Total: $6,624 USD
> Discount: 4% (already available to anyone ordering in bulk)
> 
> Shipping costs can be found at [1] and the lowest cost projections
> given. They do not offer any standard costs for shipping and cannot
> discount it.
> 
> Open source: Several products are no longer open sourced and tracking
> which is/is not can be difficult [4].
>  
> Nitrokey:
>  
> Quote received based on (150) Nitrokey Pro tokens.
> 
> Unit Price: 27,59 € ($31.58 USD at the time of this email)
> Total: 4,138.50 € ($4737.06 USD at the time of this email)
> Discount: 33% (With sponsorship agreement on gentoo.org)
>  
> All prices are already inclusive of VAT.
> 
> Shipping times can be found here [2]. Shipping costs can be found here
> [3]. The most expensive shipping is worldwide starting at 7,40 €
> ($8.47 USD at the the time of this email).
> 
> Nitrokey has also offered several unique options for Gentoo. They will
> provide a custom portal which allows each developer to request their
> security token. This is done via a Foundation (infra really) provided
> list of valid gentoo.org email addresses. Additionally, they will
> provide monthly billing of all purchased devices and the Foundation is
> not obligated to purchase all (150) tokens. This can be a standing
> agreement until the Foundation decides to remove financial support.
>  
> Considering both vendors, we can estimate shipping at the highest cost
> in order to best prepare for potential expenses.
>  
> Open source: All products are considered open [4].
>  
> -----
>  
> Motion: I move that the board vote to accept the offer from Yubico or
> Nitrokey and begin our agreement with the accepted vendor beginning 1
> September 2018. This motion will provide security tokens to all current
> developers listed in Gentoo's LDAP infrastructure as of 31 August 2018.
> 
> Motion: I move that the board vote to maintain the aforementioned
> agreement in order to support future Gentoo developers with security
> tokens. This motion includes the right to terminate future purchases
> based on the Foundation's financials.
>  
> [1]: https://www.yubico.com/support/shipping-and-buying-information/
> [2]: https://www.nitrokey.com/documentation/frequently-asked-questions#how-long-does-the-shipping-take
> [3]: https://shop.nitrokey.com/shop/product/nitrokey-pro-2-3
> [4]: https://old.lwn.net/Articles/736231/

1. Should we include all developers or only developers with gentoo.git
commit access?

2. Shouldn't we set some minimal time-as-a-dev for this?

What I'm concerned about are people joining Gentoo only to get the free
token and then stopping to contribute.  We historically had both cases
of people joining and then disappearing shortly afterwards, and people
trying to join just to gain the developer status and not to contribute.

Alternatively, require developers to return the token upon termination
of developer status, with allowance that after X years as a dev
the token is considered scrapped and does not need to be returned.

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: [gentoo-nfp] Developer Crypto Hardware (AGM)

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 983 bytes --]

On Sun, 19 Aug 2018 15:14:02 -0400 Aaron Bauman wrote:
> On Sun, Aug 19, 2018 at 09:57:16PM +0300, Andrew Savchenko wrote:
> > Hi!
> > 
> 
> [snip]
> 
> > 1. Are they open hardware? At the very least chip and board
> > schematics should be available. At best they should be reproducible
> > by third parties. 
> > 
> 
> Please see the link at [1]

Thanks. Looks good.

> > 2. How token integrity is protected during shipment?
> > 
> > Otherwise all this security enhancement will be marginal at best if
> > not fake, since if device is tampered with physically or on design
> > level, it provides no additional security, only a dangerous false
> > sense of such security enhancement.
> > 
> 
> All keys are shipped directly from the manufacturer, but I am not aware
> of anyway to garauntee the supply chain.
> 
> > Best regards,
> > Andrew Savchenko
> 
> [1]: https://github.com/Nitrokey/nitrokey-pro-hardware
> 


Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-nfp] Developer Crypto Hardware (AGM)

[Robin H. Johnson]

[-- Attachment #1: Type: text/plain, Size: 6978 bytes --]

On Sun, Aug 19, 2018 at 02:42:23PM -0400, Aaron Bauman wrote:
> Gentoo-bug: https://bugs.gentoo.org/659620
I have some discussion items & questions regarding the details of the
proposal. The questions are explicitly marked with 'Question:' so that
they stand out. I have asked questions in both roles I hold: Treasurer
of the Foundation & lead of the Infrastructure team.

1. Quantity:
(this is mostly to answer other people asking on the lists)
The Foundation has specified 150 units as the quantity for price
quoting, despite 176 developers being listed as active in LDAP. There
are multiple factors here:
- The Foundation did not want to commit to buying more keys than needed
- This may be an impetus for inactive developers to retire
- 151 developers have access to repo/gentoo.git
- 140 unique developers committed to any gentoo.org Git/CVS in the last
  6 months (123 in the last 3 months).

2. Location of developers, shipping costs:
Of the 176 developers in LDAP, here's an approximate breakdown by
location:
 89 Europe (includes EU, UK, CH, Nordics & others)
 62 USA
  7 Far-East (China, Japan, Singapore)
  7 Russia
  5 Canada
  3 Middle-East
  2 South-America
  1 Unknown

2.1 Question (from Treasurer): Based on the above, please update the
proposal to include a fair estimate of shipping as part of the approval
process. Using worst-case for those outside of Europe/USA is acceptable.
I can provide a breakdown by country for this purpose.

3. Shipping restrictions.
Yubico notes the following countries they cannot ship to:
> China, Afghanistan, Russia, Ukraine, North Korea, Iran, Sudan or Syria
Of that list, we presently, recently had or in the near future will have
(recruitment pipeline) 12 developers in: China, Russia, Ukraine, Iran

3.1 Question (from Treasurer): Does Nitrokey have by-country shipping
restrictions?

3.2 Question (from Treasurer, from Infra): If the vendor chosen of the Board
will not or cannot ship to the countries in question, what options do we
provide for developers in those countries?

4. Functionality:
Infra discussions about a potential single-sign-on system for
authentication (not commit signing) seems to be converging around OATH &
U2F systems, or the upcoming FIDO2 standard [expect new keys to be
available later this year or early next year]. The Nitrokey Pro will
offer OpenPGP only, while the YubiKey FIPS will offer both OpenPGP &
U2F. 

4.1 Question (from Infra): If the Foundation choses the Nitrokey offer,
could future provision be made to ALSO offer separate U2F/FIDO2 keys to
developers? Subject to comments by the security team, the Nitrokey U2F
would be acceptable.

5. Ownership:
As Treasurer, I would like to point out that this hardware will remain
the property of the Foundation for 6 years. This is the relevant
depreciation lifespan permitted by IRS regulations. The shipping cost
however to return an individual unit will exceed the remaining value
after 2 years (depending on the purchasing quarter, by the end of the
second financial year, 43-61% of the unit value will be depreciated).

5.1 Question (as Treasurer): As part of accepting the motions to purchase,
the Board must implement written requirements for developers to return
the keys, at their own cost, if the developer retires within 2.5 years
of ordering the unit.

(snip parts of quotes)
> All, this email will serve as a comparison between the two vendors which
> have provided quotes to the Foundation. This does not include Alice's
> proposal as U2FZero is currently out of stock in the United States and
> does not seem to offer any availability in Asia.
6. Question: Other Vendors
Are there other vendors we wish to consider or specifically exclude,
such as Feitan? Not saying we should include them, just cover that
people are aware of them.

> Alice did suggest that we split vendors across geographical markets,
> but I find this will make the situation become very difficult to
> handle. It would also put the burden on individuals to receive and
> disperse the tokens and increase shipping costs, burden the treasurer
> for reimbursements to be processed, and possibly cause delays.
As Treasurer, I would greatly prefer to paying fewer large bills rather
than many small reimbursements, or individually handling small shipping.

> Yubikey:
...
(Infra-hat) This has my preference as better product, but worse
conditions.

> Nitrokey:
>  
> Quote received based on (150) Nitrokey Pro tokens.
7. Question, as Infra: product clarification
Is this the 'Nitrokey Pro 2' as listed on the Nitrokey website, or the
older 'Nitrokey Pro'?

> All prices are already inclusive of VAT.
8. As noted on IRC, please include VAT in the estimation for Yubikey.
For Nitrokey it's covered in their FAQ:
https://www.nitrokey.com/documentation/frequently-asked-questions#pricing-and-vat

> Shipping times can be found here [2]. Shipping costs can be found here
> [3]. The most expensive shipping is worldwide starting at 7,40 €
> ($8.47 USD at the the time of this email).
> 
> Nitrokey has also offered several unique options for Gentoo. They will
> provide a custom portal which allows each developer to request their
> security token. This is done via a Foundation (infra really) provided
> list of valid gentoo.org email addresses. Additionally, they will
> provide monthly billing of all purchased devices and the Foundation is
> not obligated to purchase all (150) tokens. This can be a standing
> agreement until the Foundation decides to remove financial support.
As Treasurer, the shipping portal & monthly billing gets a big thumbs up
from me.

> Considering both vendors, we can estimate shipping at the highest cost
> in order to best prepare for potential expenses.
As noted above, please put an amount on the shipping estimate.

> Motion: I move that the board vote to accept the offer from Yubico or
> Nitrokey and begin our agreement with the accepted vendor beginning 1
> September 2018. This motion will provide security tokens to all current
> developers listed in Gentoo's LDAP infrastructure as of 31 August 2018.
> 
> Motion: I move that the board vote to maintain the aforementioned
> agreement in order to support future Gentoo developers with security
> tokens. This motion includes the right to terminate future purchases
> based on the Foundation's financials.

Please see remarks above about:
A. Treasurer: Keys to remain the property of the Foundation, and need to
   be returned if devs leave before 2.5 years.
B. Infra: Planning for U2F keys as well (I do consider it acceptable if we
   issue every developer both a NitroKey Pro & a Nitrokey U2F).

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
E-Mail   : robbat2@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 1113 bytes --]

Re: [gentoo-nfp] Developer Crypto Hardware (AGM)

[Robin H. Johnson]

[-- Attachment #1: Type: text/plain, Size: 1311 bytes --]

On Sun, Aug 19, 2018 at 09:36:42PM +0200, Michał Górny wrote:
> On Sun, 2018-08-19 at 14:42 -0400, Aaron Bauman wrote:
> > Gentoo-bug: https://bugs.gentoo.org/659620
> 1. Should we include all developers or only developers with gentoo.git
> commit access?
This is covered in my email response to b-man. Message-ID
<robbat2-20180819T200416-417951123Z@orbis-terrarum.net>

> 2. Shouldn't we set some minimal time-as-a-dev for this?
This is covered in my email response to b-man. Message-ID
<robbat2-20180819T200416-417951123Z@orbis-terrarum.net>

> Alternatively, require developers to return the token upon termination
> of developer status, with allowance that after X years as a dev
> the token is considered scrapped and does not need to be returned.
As Treasurer, the keys will remain the property of the Foundation.
Return it if X less than 2.5 years (by which time it will at least 50%
depreciated in value).

I do expect at least one retiring dev to claim that they lost it to
avoid returning it, but we'll be able to see by how (in)frequently it is
used.

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
E-Mail   : robbat2@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 1113 bytes --]

Re: [gentoo-nfp] Developer Crypto Hardware (AGM)

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1440 bytes --]

On Sun, 2018-08-19 at 22:06 +0000, Robin H. Johnson wrote:
> On Sun, Aug 19, 2018 at 09:36:42PM +0200, Michał Górny wrote:
> > On Sun, 2018-08-19 at 14:42 -0400, Aaron Bauman wrote:
> > > Gentoo-bug: https://bugs.gentoo.org/659620
> > 
> > 1. Should we include all developers or only developers with gentoo.git
> > commit access?
> 
> This is covered in my email response to b-man. Message-ID
> <robbat2-20180819T200416-417951123Z@orbis-terrarum.net>
> 
> > 2. Shouldn't we set some minimal time-as-a-dev for this?
> 
> This is covered in my email response to b-man. Message-ID
> <robbat2-20180819T200416-417951123Z@orbis-terrarum.net>
> 
> > Alternatively, require developers to return the token upon termination
> > of developer status, with allowance that after X years as a dev
> > the token is considered scrapped and does not need to be returned.
> 
> As Treasurer, the keys will remain the property of the Foundation.
> Return it if X less than 2.5 years (by which time it will at least 50%
> depreciated in value).
> 
> I do expect at least one retiring dev to claim that they lost it to
> avoid returning it, but we'll be able to see by how (in)frequently it is
> used.

Shouldn't we then formally require him to reimburse the Foundation for
the loss?  I honestly doubt that we would really enforce that but it
might be legally safer to formally request that.

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: [gentoo-nfp] Developer Crypto Hardware (AGM)

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 3956 bytes --]

On Sun, 2018-08-19 at 22:01 +0000, Robin H. Johnson wrote:
> On Sun, Aug 19, 2018 at 02:42:23PM -0400, Aaron Bauman wrote:
> > Gentoo-bug: https://bugs.gentoo.org/659620
> 
> I have some discussion items & questions regarding the details of the
> proposal. The questions are explicitly marked with 'Question:' so that
> they stand out. I have asked questions in both roles I hold: Treasurer
> of the Foundation & lead of the Infrastructure team.
> 
> 1. Quantity:
> (this is mostly to answer other people asking on the lists)
> The Foundation has specified 150 units as the quantity for price
> quoting, despite 176 developers being listed as active in LDAP. There
> are multiple factors here:
> - The Foundation did not want to commit to buying more keys than needed
> - This may be an impetus for inactive developers to retire
> - 151 developers have access to repo/gentoo.git
> - 140 unique developers committed to any gentoo.org Git/CVS in the last
>   6 months (123 in the last 3 months).

Also note that some developer have hardware tokens already, or stated
that they will get one themselves once GF selects the type.

> 4. Functionality:
> Infra discussions about a potential single-sign-on system for
> authentication (not commit signing) seems to be converging around OATH &
> U2F systems, or the upcoming FIDO2 standard [expect new keys to be
> available later this year or early next year]. The Nitrokey Pro will
> offer OpenPGP only, while the YubiKey FIPS will offer both OpenPGP &
> U2F. 

For the record, I'm not convinced about using a single device for both
purposes.  Given that some developers are using OpenPGP to encrypt
password stores, and that we are testing support for 2-step
authentication for SSH, having the same device provide both elements
might defeat the purpose of the exercise.

> 5. Ownership:
> As Treasurer, I would like to point out that this hardware will remain
> the property of the Foundation for 6 years. This is the relevant
> depreciation lifespan permitted by IRS regulations. The shipping cost
> however to return an individual unit will exceed the remaining value
> after 2 years (depending on the purchasing quarter, by the end of the
> second financial year, 43-61% of the unit value will be depreciated).
> 
> 5.1 Question (as Treasurer): As part of accepting the motions to purchase,
> the Board must implement written requirements for developers to return
> the keys, at their own cost, if the developer retires within 2.5 years
> of ordering the unit.

As mentioned in the other mail, should we account for financial
reimbursement in case developer doesn't return / loses the device? 
Furthermore, should we permit developers to keep it if they reimburse
the Foundation?  I'm not sure how far this is legally feasible.

> (snip parts of quotes)
> > All, this email will serve as a comparison between the two vendors which
> > have provided quotes to the Foundation. This does not include Alice's
> > proposal as U2FZero is currently out of stock in the United States and
> > does not seem to offer any availability in Asia.
> 
> 6. Question: Other Vendors
> Are there other vendors we wish to consider or specifically exclude,
> such as Feitan? Not saying we should include them, just cover that
> people are aware of them.

I've asked the same on IRC.  I think it might have been a better idea to
first officially announce that we're looking for the hardware with some
basic requirements, and let people reply with suggestions/offers.

> 8. As noted on IRC, please include VAT in the estimation for Yubikey.
> For Nitrokey it's covered in their FAQ:
> https://www.nitrokey.com/documentation/frequently-asked-questions#pricing-and-vat

Is anyone aware if Gentoo eV is capable of getting a VAT return for
this?  If that were the case, it might be a better idea to pass it over
to them.

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: [gentoo-nfp] Developer Crypto Hardware (AGM)

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 1852 bytes --]

On Mon, 20 Aug 2018 14:51:00 +0200 Michał Górny wrote:
> On Sun, 2018-08-19 at 22:06 +0000, Robin H. Johnson wrote:
> > On Sun, Aug 19, 2018 at 09:36:42PM +0200, Michał Górny wrote:
> > > On Sun, 2018-08-19 at 14:42 -0400, Aaron Bauman wrote:
> > > > Gentoo-bug: https://bugs.gentoo.org/659620
> > > 
> > > 1. Should we include all developers or only developers with gentoo.git
> > > commit access?
> > 
> > This is covered in my email response to b-man. Message-ID
> > <robbat2-20180819T200416-417951123Z@orbis-terrarum.net>
> > 
> > > 2. Shouldn't we set some minimal time-as-a-dev for this?
> > 
> > This is covered in my email response to b-man. Message-ID
> > <robbat2-20180819T200416-417951123Z@orbis-terrarum.net>
> > 
> > > Alternatively, require developers to return the token upon termination
> > > of developer status, with allowance that after X years as a dev
> > > the token is considered scrapped and does not need to be returned.
> > 
> > As Treasurer, the keys will remain the property of the Foundation.
> > Return it if X less than 2.5 years (by which time it will at least 50%
> > depreciated in value).
> > 
> > I do expect at least one retiring dev to claim that they lost it to
> > avoid returning it, but we'll be able to see by how (in)frequently it is
> > used.
> 
> Shouldn't we then formally require him to reimburse the Foundation for
> the loss?  I honestly doubt that we would really enforce that but it
> might be legally safer to formally request that.

How about the case when device malfunctioned or just died on its
own? Such gadgets are not very reliable and reasonable providers
recommend to have a backup one.

Anyway we can't force someone to pay for a broken device and we
have no reliable way to verify that it is indeed broken. 


Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-nfp] Developer Crypto Hardware (AGM)

[Aaron Bauman]

On August 20, 2018 9:07:48 AM EDT, Andrew Savchenko <bircoph@gentoo.org> wrote:
>On Mon, 20 Aug 2018 14:51:00 +0200 Michał Górny wrote:
>> On Sun, 2018-08-19 at 22:06 +0000, Robin H. Johnson wrote:
>> > On Sun, Aug 19, 2018 at 09:36:42PM +0200, Michał Górny wrote:
>> > > On Sun, 2018-08-19 at 14:42 -0400, Aaron Bauman wrote:
>> > > > Gentoo-bug: https://bugs.gentoo.org/659620
>> > > 
>> > > 1. Should we include all developers or only developers with
>gentoo.git
>> > > commit access?
>> > 
>> > This is covered in my email response to b-man. Message-ID
>> > <robbat2-20180819T200416-417951123Z@orbis-terrarum.net>
>> > 
>> > > 2. Shouldn't we set some minimal time-as-a-dev for this?
>> > 
>> > This is covered in my email response to b-man. Message-ID
>> > <robbat2-20180819T200416-417951123Z@orbis-terrarum.net>
>> > 
>> > > Alternatively, require developers to return the token upon
>termination
>> > > of developer status, with allowance that after X years as a dev
>> > > the token is considered scrapped and does not need to be
>returned.
>> > 
>> > As Treasurer, the keys will remain the property of the Foundation.
>> > Return it if X less than 2.5 years (by which time it will at least
>50%
>> > depreciated in value).
>> > 
>> > I do expect at least one retiring dev to claim that they lost it to
>> > avoid returning it, but we'll be able to see by how (in)frequently
>it is
>> > used.
>> 
>> Shouldn't we then formally require him to reimburse the Foundation
>for
>> the loss?  I honestly doubt that we would really enforce that but it
>> might be legally safer to formally request that.
>
>How about the case when device malfunctioned or just died on its
>own? Such gadgets are not very reliable and reasonable providers
>recommend to have a backup one.
>
>Anyway we can't force someone to pay for a broken device and we
>have no reliable way to verify that it is indeed broken. 
>
>

They would have to RMA to the manufacturer.  We can make a provision for noting responsibility of the user.

>Best regards,
>Andrew Savchenko

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [gentoo-nfp] Developer Crypto Hardware (AGM)

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 1301 bytes --]

On Mon, 20 Aug 2018 09:10:53 -0400 Aaron Bauman wrote:
> On August 20, 2018 9:07:48 AM EDT, Andrew Savchenko <bircoph@gentoo.org> wrote:
> >On Mon, 20 Aug 2018 14:51:00 +0200 Michał Górny wrote:
[...]
> >> Shouldn't we then formally require him to reimburse the Foundation
> >for
> >> the loss?  I honestly doubt that we would really enforce that but it
> >> might be legally safer to formally request that.
> >
> >How about the case when device malfunctioned or just died on its
> >own? Such gadgets are not very reliable and reasonable providers
> >recommend to have a backup one.
> >
> >Anyway we can't force someone to pay for a broken device and we
> >have no reliable way to verify that it is indeed broken. 
> >
> >
> 
> They would have to RMA to the manufacturer.  We can make a provision for noting responsibility of the user.

And if there is no RMA in the local area and/or shipment is too
expensive or the area is embargoed for the shipment? See list by
robbat2 in another reply.

I'm from Russia and this problem really bothers me. I really don't
like to take all that questionable financial responsibilities
which I may not be able to uphold to due to circumstances beyond
my control. Better not to use the gadget at all.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-nfp] Developer Crypto Hardware (AGM)

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 449 bytes --]

>>>>> On Mon, 20 Aug 2018, Michał Górny wrote:

> Is anyone aware if Gentoo eV is capable of getting a VAT return for
> this?  If that were the case, it might be a better idea to pass it over
> to them.

I think that's unlikely. The e.V. would obtain these items for the use
by its members, which qualifies as a non-commercial activity. VAT can
only be deduced for commercial activities (e.g. for items that are to be
resold).

Ulrich

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: [gentoo-nfp] Developer Crypto Hardware (AGM)

[Luca Barbato]

On 20/08/2018 18:52, Ulrich Mueller wrote:
> I think that's unlikely. The e.V. would obtain these items for the use
> by its members, which qualifies as a non-commercial activity. VAT can
> only be deduced for commercial activities (e.g. for items that are to be
> resold).

We could have a deal and actually offer branded keys for our users
during the usual conferences...

lu

Re: [gentoo-nfp] Developer Crypto Hardware (AGM)

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 730 bytes --]

On 08/20/2018 08:50 PM, Luca Barbato wrote:
> On 20/08/2018 18:52, Ulrich Mueller wrote:
>> I think that's unlikely. The e.V. would obtain these items for the use
>> by its members, which qualifies as a non-commercial activity. VAT can
>> only be deduced for commercial activities (e.g. for items that are to be
>> resold).
> 
> We could have a deal and actually offer branded keys for our users
> during the usual conferences...
> 
> lu
> 

I'd argue we're talking about spending too much money for very little
security already, without extending the scope further.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-nfp] Developer Crypto Hardware (AGM)

[Alec Warner]

[-- Attachment #1: Type: text/plain, Size: 4433 bytes --]

On Sun, Aug 19, 2018 at 2:42 PM, Aaron Bauman <bman@gentoo.org> wrote:

> Gentoo-bug: https://bugs.gentoo.org/659620
>
> All, this email will serve as a comparison between the two vendors which
> have provided quotes to the Foundation. This does not include Alice's
> proposal as U2FZero is currently out of stock in the United States and
> does not seem to offer any availability in Asia. Alice did suggest that
> we split vendors across geographical markets, but I find this will make
> the situation become very difficult to handle. It would also put the
> burden on individuals to receive and disperse the tokens and increase
> shipping costs, burden the treasurer for reimbursements to be processed,
> and possibly cause delays.
>
> Yubikey:
>
> Quote received for (150) Yubikey FIPS tokens.
>
> Unit Price: $44.16 USD
> Total: $6,624 USD
> Discount: 4% (already available to anyone ordering in bulk)
>
> Shipping costs can be found at [1] and the lowest cost projections
> given. They do not offer any standard costs for shipping and cannot
> discount it.
>
> Open source: Several products are no longer open sourced and tracking
> which is/is not can be difficult [4].
>
> Nitrokey:
>
> Quote received based on (150) Nitrokey Pro tokens.
>
> Unit Price: 27,59 € ($31.58 USD at the time of this email)
> Total: 4,138.50 € ($4737.06 USD at the time of this email)
> Discount: 33% (With sponsorship agreement on gentoo.org)
>
> All prices are already inclusive of VAT.
>
> Shipping times can be found here [2]. Shipping costs can be found here
> [3]. The most expensive shipping is worldwide starting at 7,40 €
> ($8.47 USD at the the time of this email).
>
> Nitrokey has also offered several unique options for Gentoo. They will
> provide a custom portal which allows each developer to request their
> security token. This is done via a Foundation (infra really) provided
> list of valid gentoo.org email addresses. Additionally, they will
> provide monthly billing of all purchased devices and the Foundation is
> not obligated to purchase all (150) tokens. This can be a standing
> agreement until the Foundation decides to remove financial support.
>
> Considering both vendors, we can estimate shipping at the highest cost
> in order to best prepare for potential expenses.
>
> Open source: All products are considered open [4].
>
> -----
>
> Motion: I move that the board vote to accept the offer from Yubico or
> Nitrokey and begin our agreement with the accepted vendor beginning 1
> September 2018. This motion will provide security tokens to all current
> developers listed in Gentoo's LDAP infrastructure as of 31 August 2018.
>

Without a more concrete proposal on the benefit of the keys, I cannot vote
in the affirmative.

 - Will we require keys to commit to git?
 - Can we even measure key usage?
 - Are the keys only for signing git commits, or are there other activities
that are under this proposal?

One narrative might be something like:

1) We surveyed developers and found that 10% use hardware tokens today (so
like ~15 people).
2) We ordered N keys, and offered them under a program as an exploratory
measure, we hand out 100% of the keys.
3) We surveyed developers again and found that now, reported key usage
increased by +X00% (e.g. we ordered 50 keys and now 40 people use them, an
increase of 200%.)
4) We expand the program and order another N keys.

So we might fund this as a program to improve key usage via self-reported
developer surveys; the idea being that 'most' developers use a hardware key
on commit and the foundation thinks this provides a good benefit.

Are there other ways to measure if the keys are used in the manner we are
hoping for?

-A


> Motion: I move that the board vote to maintain the aforementioned
> agreement in order to support future Gentoo developers with security
> tokens. This motion includes the right to terminate future purchases
> based on the Foundation's financials.
>

This is fine provided we pass the first motion.


>
> [1]: https://www.yubico.com/support/shipping-and-buying-information/
> [2]: https://www.nitrokey.com/documentation/frequently-
> asked-questions#how-long-does-the-shipping-take
> [3]: https://shop.nitrokey.com/shop/product/nitrokey-pro-2-3
> [4]: https://old.lwn.net/Articles/736231/
>
> --
> Cheers,
> Aaron
>

[-- Attachment #2: Type: text/html, Size: 6115 bytes --]

Re: [gentoo-nfp] Developer Crypto Hardware (AGM)

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 1238 bytes --]

On 08/20/2018 10:18 PM, Alec Warner wrote:
> Are there other ways to measure if the keys are used in the manner we are
> hoping for?

Nope... additional complexity arise if multiple signing keys exists
(primary or subkeys), and furthermore there is no guarantee the key is
stored on key only.

That said, the actual security is even further muddied by operational
security concerns regarding how the primary key is accessed even in the
event signing subkey is on card only.. and other security precations
required by the developers for the token to have any meaningful addition
to security as an attacker can anyways just wait for it to be be
available, in particular if not mandating forcesig on the openpgp applet
and counting the number of signatures manually to detect abnormalities.

I really would like to see a properly written up memorandum on the
threat model this suggestion is intended to protect against and the
cost/benefit analysis involved in the decision making; to me it sounds
like some people think it is a panacea without much actual considerations.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-nfp] Developer Crypto Hardware (AGM)

[Alec Warner]

[-- Attachment #1: Type: text/plain, Size: 1949 bytes --]

On Mon, Aug 20, 2018 at 4:27 PM, Kristian Fiskerstrand <k_f@gentoo.org>
wrote:

> On 08/20/2018 10:18 PM, Alec Warner wrote:
> > Are there other ways to measure if the keys are used in the manner we are
> > hoping for?
>
> Nope... additional complexity arise if multiple signing keys exists
> (primary or subkeys), and furthermore there is no guarantee the key is
> stored on key only.
>

> That said, the actual security is even further muddied by operational
> security concerns regarding how the primary key is accessed even in the
> event signing subkey is on card only.. and other security precations
> required by the developers for the token to have any meaningful addition
> to security as an attacker can anyways just wait for it to be be
> available, in particular if not mandating forcesig on the openpgp applet
> and counting the number of signatures manually to detect abnormalities.
>

I assert that the hardware token, when the key is stored only in the token
and not in another place online, prevents export of key material.
This limits attackers who instead of:

 - Getting on my box once and stealing my keys.
 - Now has to maintain persistence on the machine that my token is
available on.
   - Add a hook to detect when the token is unlocked.
   - Do all the sign operations during the unlock window.
   - Avoid detection during all of this.

Its certainly not impossible, but its harder than just key theft. Is it
worth 4000$? Is the 4000 better spent on other controls? Unclear.

-A


> I really would like to see a properly written up memorandum on the
> threat model this suggestion is intended to protect against and the
> cost/benefit analysis involved in the decision making; to me it sounds
> like some people think it is a panacea without much actual considerations.
>
> --
> Kristian Fiskerstrand
> OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
> fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
>
>

[-- Attachment #2: Type: text/html, Size: 2874 bytes --]

Re: [gentoo-nfp] Developer Crypto Hardware (AGM)

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 1068 bytes --]

On 08/20/2018 10:57 PM, Alec Warner wrote:
> I assert that the hardware token, when the key is stored only in the token
> and not in another place online, prevents export of key material.
> This limits attackers who instead of:
> 
>  - Getting on my box once and stealing my keys.
>  - Now has to maintain persistence on the machine that my token is
> available on.
>    - Add a hook to detect when the token is unlocked.
>    - Do all the sign operations during the unlock window.
>    - Avoid detection during all of this.
> 
> Its certainly not impossible, but its harder than just key theft. Is it
> worth 4000$? Is the 4000 better spent on other controls? Unclear.

Right.. which is a big benefit for long term key material, and against
an APT that has compromised the hardware of the computer (which happens
regularly), but isn't necessarily something that helps in the case of
Gentoo use case.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-nfp] Developer Crypto Hardware (AGM)

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 1592 bytes --]

On Mon, 20 Aug 2018 16:57:52 -0400 Alec Warner wrote:
> On Mon, Aug 20, 2018 at 4:27 PM, Kristian Fiskerstrand <k_f@gentoo.org>
> wrote:
> 
> > On 08/20/2018 10:18 PM, Alec Warner wrote:
> > > Are there other ways to measure if the keys are used in the manner we are
> > > hoping for?
> >
> > Nope... additional complexity arise if multiple signing keys exists
> > (primary or subkeys), and furthermore there is no guarantee the key is
> > stored on key only.
> >
> 
> > That said, the actual security is even further muddied by operational
> > security concerns regarding how the primary key is accessed even in the
> > event signing subkey is on card only.. and other security precations
> > required by the developers for the token to have any meaningful addition
> > to security as an attacker can anyways just wait for it to be be
> > available, in particular if not mandating forcesig on the openpgp applet
> > and counting the number of signatures manually to detect abnormalities.
> >
> 
> I assert that the hardware token, when the key is stored only in the token
> and not in another place online, prevents export of key material.

No, it doesn't. The cost of extracting a key from a stolen token is
approximately $1000 depending on a token model.

The problem is that people are considering a token as a silver
bullet protecting them reliably. While protection will be indeed
improved a bit, this is all the gain; and relaxed state of false
security may prove to be more dangerous than not to have tokens at
all.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-nfp] Developer Crypto Hardware (AGM)

[Aaron Bauman]

On August 20, 2018 7:26:38 PM EDT, Andrew Savchenko <bircoph@gentoo.org> wrote:
>On Mon, 20 Aug 2018 16:57:52 -0400 Alec Warner wrote:
>> On Mon, Aug 20, 2018 at 4:27 PM, Kristian Fiskerstrand
><k_f@gentoo.org>
>> wrote:
>> 
>> > On 08/20/2018 10:18 PM, Alec Warner wrote:
>> > > Are there other ways to measure if the keys are used in the
>manner we are
>> > > hoping for?
>> >
>> > Nope... additional complexity arise if multiple signing keys exists
>> > (primary or subkeys), and furthermore there is no guarantee the key
>is
>> > stored on key only.
>> >
>> 
>> > That said, the actual security is even further muddied by
>operational
>> > security concerns regarding how the primary key is accessed even in
>the
>> > event signing subkey is on card only.. and other security
>precations
>> > required by the developers for the token to have any meaningful
>addition
>> > to security as an attacker can anyways just wait for it to be be
>> > available, in particular if not mandating forcesig on the openpgp
>applet
>> > and counting the number of signatures manually to detect
>abnormalities.
>> >
>> 
>> I assert that the hardware token, when the key is stored only in the
>token
>> and not in another place online, prevents export of key material.
>
>No, it doesn't. The cost of extracting a key from a stolen token is
>approximately $1000 depending on a token model.
>
>The problem is that people are considering a token as a silver
>bullet protecting them reliably. While protection will be indeed
>improved a bit, this is all the gain; and relaxed state of false
>security may prove to be more dangerous than not to have tokens at
>all.
>
>Best regards,
>Andrew Savchenko

Do you always negate yourself in the same sentence?  No one has said this is a silver bullet.  No one has advocated that anyone can sit back and relax because they now have a magical token.

-Aaron
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [gentoo-nfp] Developer Crypto Hardware (AGM)

[Alec Warner]

[-- Attachment #1: Type: text/plain, Size: 4246 bytes --]

On Mon, Aug 20, 2018 at 7:26 PM, Andrew Savchenko <bircoph@gentoo.org>
wrote:

> On Mon, 20 Aug 2018 16:57:52 -0400 Alec Warner wrote:
> > On Mon, Aug 20, 2018 at 4:27 PM, Kristian Fiskerstrand <k_f@gentoo.org>
> > wrote:
> >
> > > On 08/20/2018 10:18 PM, Alec Warner wrote:
> > > > Are there other ways to measure if the keys are used in the manner
> we are
> > > > hoping for?
> > >
> > > Nope... additional complexity arise if multiple signing keys exists
> > > (primary or subkeys), and furthermore there is no guarantee the key is
> > > stored on key only.
> > >
> >
> > > That said, the actual security is even further muddied by operational
> > > security concerns regarding how the primary key is accessed even in the
> > > event signing subkey is on card only.. and other security precations
> > > required by the developers for the token to have any meaningful
> addition
> > > to security as an attacker can anyways just wait for it to be be
> > > available, in particular if not mandating forcesig on the openpgp
> applet
> > > and counting the number of signatures manually to detect abnormalities.
> > >
> >
> > I assert that the hardware token, when the key is stored only in the
> token
> > and not in another place online, prevents export of key material.
>

> No, it doesn't. The cost of extracting a key from a stolen token is
> approximately $1000 depending on a token model.
>

Sigh, I'll try to use better words in the future.


>
> The problem is that people are considering a token as a silver
> bullet protecting them reliably. While protection will be indeed
> improved a bit, this is all the gain; and relaxed state of false
> security may prove to be more dangerous than not to have tokens at
> all.
>

In security, the goal is to protect an asset valued at Y. We may spend X to
protect that asset. Generally X << Y; if you spend more than the asset was
worth in protection, it would be a waste of resources. So my goal here is
not to "build a system no one can hack into" that is a silly idea.

This is true throughout the industry. Security is a series of cost benefit
tradeoffs. For example, car keys are generally fairly high quality with
extra security features (e.g. an Immobilizer and encrypted or rotated
codes) vs a set of housekeys. Housekeys can typically be made for < 5$ per
key at a machine in a store, and the locking mechanisms range from about
$20 to $400+. All of these features are moot if the attacker wants to be
loud. The CIA lockpicking manual[0] for instance has a conclusion that is
basically "you can probably drill out the lock and replace it faster than
you can pick it."

Safes are similar[1], and are rated for various 'times it takes a skilled
person to break into"; many of the higher ratings require anchoring as its
unlikely for attackers to gain lots of time with a safe unsupervised, so
they steal the safe and work on them offsite where time is more easily
available.

So when you make a counter argument like "well the attacker could
physically come take your token and spend 1000$ extracting the key" my
assertion is not that "well that is impossible" my assertion is that
"Great, the attacker has to *physically steal my key* and commit a crime,
then spend 1000$." The whole point is to make the attack annoying and not
worthwhile, not to literally make it impossible.

The attacks I care about are nominally:

1) I want to force attackers to need persistent access to systems to
succeed. This means they leave more evidence and commit more crimes, which
means if bad stuff happens we can take legal action. I believe HW tokens
help with this.
2) I want to force attackers to need physical access to systems to succeed.
This means attackers likely commit crimes (like breaking and entering,
theft, etc) and they might even commit them in a jurisdiction where they
are prosecuted, particularly in jurisdictions where developers are present.
Hardware tokens help here too.

Even after all this I'm not convinced the keys are useful, but I'm also not
trying to say they are a silver bullet; just another layer of defense.

[0] https://archive.org/details/pdfy-eGBVTYko5TUI5P_B
[1] https://www.safeandvaultstore.com/pages/burglary-ratings

-A


> Best regards,
> Andrew Savchenko
>

[-- Attachment #2: Type: text/html, Size: 5990 bytes --]

Re: [gentoo-nfp] Developer Crypto Hardware (AGM)

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1573 bytes --]

On Tue, 2018-08-21 at 02:26 +0300, Andrew Savchenko wrote:
> On Mon, 20 Aug 2018 16:57:52 -0400 Alec Warner wrote:
> > On Mon, Aug 20, 2018 at 4:27 PM, Kristian Fiskerstrand <k_f@gentoo.org>
> > wrote:
> > 
> > > On 08/20/2018 10:18 PM, Alec Warner wrote:
> > > > Are there other ways to measure if the keys are used in the manner we are
> > > > hoping for?
> > > 
> > > Nope... additional complexity arise if multiple signing keys exists
> > > (primary or subkeys), and furthermore there is no guarantee the key is
> > > stored on key only.
> > > 
> > > That said, the actual security is even further muddied by operational
> > > security concerns regarding how the primary key is accessed even in the
> > > event signing subkey is on card only.. and other security precations
> > > required by the developers for the token to have any meaningful addition
> > > to security as an attacker can anyways just wait for it to be be
> > > available, in particular if not mandating forcesig on the openpgp applet
> > > and counting the number of signatures manually to detect abnormalities.
> > > 
> > 
> > I assert that the hardware token, when the key is stored only in the token
> > and not in another place online, prevents export of key material.
> 
> No, it doesn't. The cost of extracting a key from a stolen token is
> approximately $1000 depending on a token model.

What is the cost of extracting a key from a stolen hard drive?

What are the costs of other attack vectors on Gentoo, for comparison?

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: [gentoo-nfp] Developer Crypto Hardware (AGM)

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 464 bytes --]

On 08/21/2018 03:59 AM, Alec Warner wrote:
> Even after all this I'm not convinced the keys are useful, but I'm also not
> trying to say they are a silver bullet; just another layer of defense.

For a dedicated attacker one possible is to become a gentoo dev and wait
for an opportune moment to attack though.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-nfp] Developer Crypto Hardware (AGM)

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 1996 bytes --]

On Tue, 21 Aug 2018 08:44:22 +0200 Michał Górny wrote:
> On Tue, 2018-08-21 at 02:26 +0300, Andrew Savchenko wrote:
> > On Mon, 20 Aug 2018 16:57:52 -0400 Alec Warner wrote:
> > > On Mon, Aug 20, 2018 at 4:27 PM, Kristian Fiskerstrand <k_f@gentoo.org>
> > > wrote:
> > > 
> > > > On 08/20/2018 10:18 PM, Alec Warner wrote:
> > > > > Are there other ways to measure if the keys are used in the manner we are
> > > > > hoping for?
> > > > 
> > > > Nope... additional complexity arise if multiple signing keys exists
> > > > (primary or subkeys), and furthermore there is no guarantee the key is
> > > > stored on key only.
> > > > 
> > > > That said, the actual security is even further muddied by operational
> > > > security concerns regarding how the primary key is accessed even in the
> > > > event signing subkey is on card only.. and other security precations
> > > > required by the developers for the token to have any meaningful addition
> > > > to security as an attacker can anyways just wait for it to be be
> > > > available, in particular if not mandating forcesig on the openpgp applet
> > > > and counting the number of signatures manually to detect abnormalities.
> > > > 
> > > 
> > > I assert that the hardware token, when the key is stored only in the token
> > > and not in another place online, prevents export of key material.
> > 
> > No, it doesn't. The cost of extracting a key from a stolen token is
> > approximately $1000 depending on a token model.
> 
> What is the cost of extracting a key from a stolen hard drive?

Keys on my hard drive have double encryption using independent
algorithms and passwords. So if we are talking about cost of
retrieving such case from hard drive alone (and not other attack
vectors), it will be infinite.
 
> What are the costs of other attack vectors on Gentoo, for comparison?

Please specify other attack vectors to have well founded further
discussion.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-nfp] Developer Crypto Hardware (AGM)

[Rich Freeman]

On Mon, Aug 20, 2018 at 7:26 PM Andrew Savchenko <bircoph@gentoo.org> wrote:
>
> No, it doesn't. The cost of extracting a key from a stolen token is
> approximately $1000 depending on a token model.
>

I'll have to ask for a citation on that one.

I think the satellite TV industry did quite a bit to make hardware
tokens VERY resistant to tampering.  Maybe a few state actors could
defeat them, but if Chinese intelligence needed to infiltrate us I'm
sure they'd figure out a way to do it.  The NSA probably has a hard
enough time keeping them out of stuff.

IMO the main threat model for Gentoo is the script kiddie who wants to
stick rm -rf / in all our ebuilds, and actually knows how to do it
correctly.  Unless we move to a model that has much more sophisticated
QA (release-based, peer-review, CI, etc) we're not going to be defeat
more complex attacks, because right now any Gentoo dev with commit
access can basically do whatever they want, and becoming a dev isn't
that hard for somebody who is determined.

I'm not saying that tokens are uber-powerful or that they're a waste.
They have some pros/cons.  On the whole they're probably a good idea,
but honestly the fact that devs are going to have to pay to return
them/etc limits their value, especially since the whole openpgp
smartcard standard already limits their utility quite a bit, and key
recovery is still a tricky problem for orgs where people don't
routinely see each other in person or at least know each other by
voice.

-- 
Rich

Re: [gentoo-nfp] Developer Crypto Hardware (AGM)

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 4452 bytes --]

Hi!

On Tue, 21 Aug 2018 09:42:28 -0400 Rich Freeman wrote:
> On Mon, Aug 20, 2018 at 7:26 PM Andrew Savchenko <bircoph@gentoo.org> wrote:
> >
> > No, it doesn't. The cost of extracting a key from a stolen token is
> > approximately $1000 depending on a token model.
> >
> 
> I'll have to ask for a citation on that one.

Fine.

First and foremost source is already available from web archive
only:
https://web.archive.org/web/20180710200252/https://community.st.com/thread/46432-hacking-readout-protection-on-stm32

Some technical details:
https://www.aisec.fraunhofer.de/en/FirmwareProtection.html

Some services and prises:
http://www.ic-cracker.com/
http://www.unlock-ic.com/
https://russiansemiresearch.com/en/service/#read_prot

It doesn't matter if chips inside some tokens are not on the list
above, this is the industry wide problem. Physically there is no
such device as read protected memory cell. Only technological size
of the cell provides some minimal protection: it is easier to read
500 nm cell than 20 nm. That's all. No further protection is or may
be available.

Furthermore I hope you understand that not all information is
available via clearnet links and not everything is disclosured on
the net due to NDA or similar agreements. The real state of matter
is much worse than in the links above and industry for reading
"protected" devices is well established, growing and affordable.

The only possible way to protect from such attacks is not to store
unencrypted key material on token at all, e.g. have it password
protected, temporary save unencrypted bits only in RAM and guarantee
that RAM cells and all aux registers will be securely wiped out
without any residual storage after its usage. I don't know such
devices though, since all of them rely on principle "one can't read
bits from our storage".

> I think the satellite TV industry did quite a bit to make hardware
> tokens VERY resistant to tampering.

Sorry what? Satellite TV is quite trivial to break without any
preacquired tokens at all. Its encryption is busted by design.

> Maybe a few state actors could
> defeat them, but if Chinese intelligence needed to infiltrate us I'm
> sure they'd figure out a way to do it.  The NSA probably has a hard
> enough time keeping them out of stuff.

Ha-ha. As Mr. Snowden have shown NSA can't even control its own
data.

> IMO the main threat model for Gentoo is the script kiddie who wants to
> stick rm -rf / in all our ebuilds, and actually knows how to do it
> correctly.  Unless we move to a model that has much more sophisticated
> QA (release-based, peer-review, CI, etc) we're not going to be defeat
> more complex attacks, because right now any Gentoo dev with commit
> access can basically do whatever they want, and becoming a dev isn't
> that hard for somebody who is determined.

IMO you are trying to mix technical and social problems here. Indeed
determined individual may infiltrate any free software organization
accepting new members (or buy some long-term developer, or force
them via some secret court gag order), but an impact from such
infiltration will be likely limited to a single attack which will
result in administrative (e.g. kicking out) and possibly legal
action and preparation for such attack will require too much time
and money, so gain-to-effort ratio will be quite low.

> I'm not saying that tokens are uber-powerful or that they're a waste.
> They have some pros/cons.  On the whole they're probably a good idea,
> but honestly the fact that devs are going to have to pay to return
> them/etc limits their value, especially since the whole openpgp
> smartcard standard already limits their utility quite a bit, and key
> recovery is still a tricky problem for orgs where people don't
> routinely see each other in person or at least know each other by
> voice.

I fully agree that tokens are just another layer of security. But
sometimes additional security layers reduce practical security due
to social effects: e.g. cyclist wearing good helmets and other
protection are inclined to more dangerous driving since they have
a false sense of being secure in a good helmet. The same with
hardware tokens: their users are often less careful with other
measures like password hygiene or strength because they imply they
are well protected by a token already.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-nfp] Developer Crypto Hardware (AGM)

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 3518 bytes --]

Hi!

On Mon, 20 Aug 2018 21:59:22 -0400 Alec Warner wrote:
> On Mon, Aug 20, 2018 at 7:26 PM, Andrew Savchenko <bircoph@gentoo.org>
> wrote:
[...]
> > The problem is that people are considering a token as a silver
> > bullet protecting them reliably. While protection will be indeed
> > improved a bit, this is all the gain; and relaxed state of false
> > security may prove to be more dangerous than not to have tokens at
> > all.
> >
> 
> In security, the goal is to protect an asset valued at Y. We may spend X to
> protect that asset. Generally X << Y; if you spend more than the asset was
> worth in protection, it would be a waste of resources. So my goal here is
> not to "build a system no one can hack into" that is a silly idea.

Sure. The only question here is how much is they value of Y? How
much all work hours spent on Gentoo cost? How much its reputation
acquired over ~20 years costs? I have no easy answers for these
questions, but I assume Y is not small.

> This is true throughout the industry. Security is a series of cost benefit
> tradeoffs. For example, car keys are generally fairly high quality with
> extra security features (e.g. an Immobilizer and encrypted or rotated
> codes) vs a set of housekeys. Housekeys can typically be made for < 5$ per
> key at a machine in a store, and the locking mechanisms range from about
> $20 to $400+. All of these features are moot if the attacker wants to be
> loud. The CIA lockpicking manual[0] for instance has a conclusion that is
> basically "you can probably drill out the lock and replace it faster than
> you can pick it."

There are plenty of doors and locks with protection from drilling
out locks or cutting hinges protection :) And they are not that
expensive at all.

> Safes are similar[1], and are rated for various 'times it takes a skilled
> person to break into"; many of the higher ratings require anchoring as its
> unlikely for attackers to gain lots of time with a safe unsupervised, so
> they steal the safe and work on them offsite where time is more easily
> available.

The only goal of every physical safe is to give some *time* if an
attack (either break-in or fire) is ongoing. This doesn't apply to a
repository or infrastructure protection we're discussing — unless
we're discussing how long it will take to break through good
symmetric encryption, but apparently we want to protect from other
attack vectors.

> So when you make a counter argument like "well the attacker could
> physically come take your token and spend 1000$ extracting the key" my
> assertion is not that "well that is impossible" my assertion is that
> "Great, the attacker has to *physically steal my key* and commit a crime,
> then spend 1000$." The whole point is to make the attack annoying and not
> worthwhile, not to literally make it impossible.

One may loose a key accidentally or it will look like an accident,
especially after a social event. It will be hard to impossible
prove any criminal intent if someone will just find your token.

Furthermore tokens may be busted during shipment or production.
This will almost nullify their security. These are very vulnerable
operations easy to backdoor and hard to make them secure.

And last but not the least: laws are quite different in different
areas and it is dangerous to rely on them for information security.
Usually they are the last line of defense when technical means fail.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-nfp] Developer Crypto Hardware (AGM)

[Alec Warner]

[-- Attachment #1: Type: text/plain, Size: 5645 bytes --]

On Wed, Aug 22, 2018 at 12:13 AM Andrew Savchenko <bircoph@gentoo.org>
wrote:

> Hi!
>
> On Mon, 20 Aug 2018 21:59:22 -0400 Alec Warner wrote:
> > On Mon, Aug 20, 2018 at 7:26 PM, Andrew Savchenko <bircoph@gentoo.org>
> > wrote:
> [...]
> > > The problem is that people are considering a token as a silver
> > > bullet protecting them reliably. While protection will be indeed
> > > improved a bit, this is all the gain; and relaxed state of false
> > > security may prove to be more dangerous than not to have tokens at
> > > all.
> > >
> >
> > In security, the goal is to protect an asset valued at Y. We may spend X
> to
> > protect that asset. Generally X << Y; if you spend more than the asset
> was
> > worth in protection, it would be a waste of resources. So my goal here is
> > not to "build a system no one can hack into" that is a silly idea.
>
> Sure. The only question here is how much is they value of Y? How
> much all work hours spent on Gentoo cost? How much its reputation
> acquired over ~20 years costs? I have no easy answers for these
> questions, but I assume Y is not small.
>

My point is perhaps less the size of Y, and mostly that the size of X is
small. The Foundation has about 120k in the bank, so the security we can
fund is limited. E.g. below you discuss supply chain attacks, but the
foundation cannot afford to build a secure supply chain for the hardware it
might purchase; and developers use hardware outside of this supply chain
anyway. This basically leads to an security assumption:

 - Our supply chain is not secure (because we don't really have one.)
 - Attackers who can attack the supply chain can attack Gentoo.

Note that this is no different than most companies; so I don't think we are
*worse* off for having this stance. Is it not ideal? Sure. But its what we
can afford.


> > This is true throughout the industry. Security is a series of cost
> benefit
> > tradeoffs. For example, car keys are generally fairly high quality with
> > extra security features (e.g. an Immobilizer and encrypted or rotated
> > codes) vs a set of housekeys. Housekeys can typically be made for < 5$
> per
> > key at a machine in a store, and the locking mechanisms range from about
> > $20 to $400+. All of these features are moot if the attacker wants to be
> > loud. The CIA lockpicking manual[0] for instance has a conclusion that is
> > basically "you can probably drill out the lock and replace it faster than
> > you can pick it."
>
> There are plenty of doors and locks with protection from drilling
> out locks or cutting hinges protection :) And they are not that
> expensive at all.
>

I'm not aware of anyone selling an unbreakable door. Even the 'protection'
you mention is not full proof. What it does is requires more noise (bigger
saw, for locks, typically) and more time for the attacker to spend; and
more noise for the attack. These are all good attributes as they increase
attack risk. The security key is IMHO, similar. Attackers have to spend
1000$, they need to find someone who can extract the material (maybe the
attacker lacks this capability in house, etc.)


>
> > Safes are similar[1], and are rated for various 'times it takes a skilled
> > person to break into"; many of the higher ratings require anchoring as
> its
> > unlikely for attackers to gain lots of time with a safe unsupervised, so
> > they steal the safe and work on them offsite where time is more easily
> > available.
>
> The only goal of every physical safe is to give some *time* if an
> attack (either break-in or fire) is ongoing. This doesn't apply to a
> repository or infrastructure protection we're discussing — unless
> we're discussing how long it will take to break through good
> symmetric encryption, but apparently we want to protect from other
> attack vectors.
>




>
> > So when you make a counter argument like "well the attacker could
> > physically come take your token and spend 1000$ extracting the key" my
> > assertion is not that "well that is impossible" my assertion is that
> > "Great, the attacker has to *physically steal my key* and commit a crime,
> > then spend 1000$." The whole point is to make the attack annoying and not
> > worthwhile, not to literally make it impossible.
>
> One may loose a key accidentally or it will look like an accident,
> especially after a social event. It will be hard to impossible
> prove any criminal intent if someone will just find your token.
>

Again, this is a very expensive attack. I'm not worried about it, because
people willing to spend money can already break into Gentoo.


>
> Furthermore tokens may be busted during shipment or production.
> This will almost nullify their security. These are very vulnerable
> operations easy to backdoor and hard to make them secure.
>

The computer I generated my keys on also lacked a secure supply chain...so
I'm not sure how this is any worse. At some point you must accept risks;
otherwise building anything becomes too expensive.


> And last but not the least: laws are quite different in different
> areas and it is dangerous to rely on them for information security.
> Usually they are the last line of defense when technical means fail.


I'm seeing a lot of 'security keys are bad' and FWIW I appreciate the
skepticism of the idea. However, I am looking for a bit more constructive
feedback here. Lets say we don't buy keys; do you have any ideas on how we
can improve the security of our GPG infrastructure?

-A


>
> Best regards,
> Andrew Savchenko
>

[-- Attachment #2: Type: text/html, Size: 7258 bytes --]

Re: [gentoo-nfp] Developer Crypto Hardware (AGM)

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 1163 bytes --]

On 08/22/2018 02:26 PM, Alec Warner wrote:
>  do you have any ideas on how we
> can improve the security of our GPG infrastructure?

(i) Using it more in our operations to begin with, including but not
limited to [bugzilla]

(ii) Increase [WoT connectivity] / more fingerprint exchanges

(iii) more awareness and use of OpenPGP in general amongst developers,
i.e it becomes part of routine to secure communications (how many are
signing their emails in this discussion?) and perform integrity
verification more extensively. Maybe we should start documenting the
results of signature verification as part of package bump commit
messages? Or do devs simply bump without verifying integrity of the
upstream package to begin with? We should likely also work with
upstreams that do not provide signatures for release tarballs to
actually do so.

References:
[bugzilla]
https://bugs.gentoo.org/624262

[WoT connectivity]
https://download.sumptuouscapital.com/gentoo/openpgp-wot/gentoo-devs.pdf


-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-nfp] Developer Crypto Hardware (AGM)

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 1492 bytes --]

On 08/22/2018 02:52 PM, Kristian Fiskerstrand wrote:
> On 08/22/2018 02:26 PM, Alec Warner wrote:
>>  do you have any ideas on how we
>> can improve the security of our GPG infrastructure?
> 
> (i) Using it more in our operations to begin with, including but not
> limited to [bugzilla]
> 
> (ii) Increase [WoT connectivity] / more fingerprint exchanges
> 
> (iii) more awareness and use of OpenPGP in general amongst developers,
> i.e it becomes part of routine to secure communications (how many are
> signing their emails in this discussion?) and perform integrity
> verification more extensively. Maybe we should start documenting the
> results of signature verification as part of package bump commit
> messages? Or do devs simply bump without verifying integrity of the
> upstream package to begin with? We should likely also work with
> upstreams that do not provide signatures for release tarballs to
> actually do so.
> 

Forgot to add that one thing that we can also look into is a Gentoo
Developer CA, i.e sign the developer's gentoo UID for those actually
devs so it can be used for verification by third parties ahead of contact.

> References:
> [bugzilla]
> https://bugs.gentoo.org/624262
> 
> [WoT connectivity]
> https://download.sumptuouscapital.com/gentoo/openpgp-wot/gentoo-devs.pdf
> 
> 


-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-nfp] Developer Crypto Hardware (AGM)

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 3461 bytes --]

On Tue, 2018-08-21 at 14:44 +0300, Andrew Savchenko wrote:
> On Tue, 21 Aug 2018 08:44:22 +0200 Michał Górny wrote:
> > On Tue, 2018-08-21 at 02:26 +0300, Andrew Savchenko wrote:
> > > On Mon, 20 Aug 2018 16:57:52 -0400 Alec Warner wrote:
> > > > On Mon, Aug 20, 2018 at 4:27 PM, Kristian Fiskerstrand <k_f@gentoo.org>
> > > > wrote:
> > > > 
> > > > > On 08/20/2018 10:18 PM, Alec Warner wrote:
> > > > > > Are there other ways to measure if the keys are used in the manner we are
> > > > > > hoping for?
> > > > > 
> > > > > Nope... additional complexity arise if multiple signing keys exists
> > > > > (primary or subkeys), and furthermore there is no guarantee the key is
> > > > > stored on key only.
> > > > > 
> > > > > That said, the actual security is even further muddied by operational
> > > > > security concerns regarding how the primary key is accessed even in the
> > > > > event signing subkey is on card only.. and other security precations
> > > > > required by the developers for the token to have any meaningful addition
> > > > > to security as an attacker can anyways just wait for it to be be
> > > > > available, in particular if not mandating forcesig on the openpgp applet
> > > > > and counting the number of signatures manually to detect abnormalities.
> > > > > 
> > > > 
> > > > I assert that the hardware token, when the key is stored only in the token
> > > > and not in another place online, prevents export of key material.
> > > 
> > > No, it doesn't. The cost of extracting a key from a stolen token is
> > > approximately $1000 depending on a token model.
> > 
> > What is the cost of extracting a key from a stolen hard drive?
> 
> Keys on my hard drive have double encryption using independent
> algorithms and passwords. So if we are talking about cost of
> retrieving such case from hard drive alone (and not other attack
> vectors), it will be infinite.

What if you install a malicious GnuPG upgrade that leaks your secret key
material upon decryption?

It's not that hard.  In fact, if right now our 'gpg --version' output
'This version has been hacked by Gentoo to prove how easy it is to
release hacked software without anyone noticing', how many users would
actually notice that?  And we're talking about *easily visible* change
vs silent behavior that can easily be implemented without raising any
suspicion, especially given that gpg2 operates almost entirely
in the background.  I mean, you could do it without any user-visible
slowdown, additional processes etc.

How could it happen?  Let's say that a Gentoo maintainer account is
compromised.  When a new version of GnuPG is released, the account is
used to perform the bump using a malicious tarball hosted on Gentoo
Infra.  Of course, this would probably be noticed sooner or later,
though replacing it with a valid bump shortly afterwards reduces
the chance of detecting it in time.  Before we can deal even with
establishing how many developers were affected, the attacker can have
dozens of private keys ready to be used.

This is one attack vector that -- AFAIU -- hardware tokens protect
against.  The attacker can find a way to use the key remotely but he
can't obtain it.  Of course, you can now start arguing that's bad enough
as it is, so making it worse doesn't matter.

PS. I wonder how many users checked our 'gpg --version' at this point.

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: [gentoo-nfp] Developer Crypto Hardware (AGM)

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 820 bytes --]

On 08/22/2018 03:37 PM, Michał Górny wrote:
> This is one attack vector that -- AFAIU -- hardware tokens protect
> against. 

Right, although it only shifts the attack, so user would just wait until
the token is available to perform whatever wanted anyways. In terms of
after the attack, the difference is we don't really use OpenPGP as a
long term identify such as it is in general. For a user, losing WoT etc
can have an impact, for Gentoo we just update LDAP and access is
effectively revoked without further issues, we don't need the key
material to survive this attack to be used after the fact again, which
is really what the hardware token helps for.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-nfp] Developer Crypto Hardware (AGM)

[Rich Freeman]

On Wed, Aug 22, 2018 at 9:48 AM Kristian Fiskerstrand <k_f@gentoo.org> wrote:
>
> On 08/22/2018 03:37 PM, Michał Górny wrote:
> > This is one attack vector that -- AFAIU -- hardware tokens protect
> > against.
>
> Right, although it only shifts the attack, so user would just wait until
> the token is available to perform whatever wanted anyways. In terms of
> after the attack, the difference is we don't really use OpenPGP as a
> long term identify such as it is in general. For a user, losing WoT etc
> can have an impact, for Gentoo we just update LDAP and access is
> effectively revoked without further issues, we don't need the key
> material to survive this attack to be used after the fact again, which
> is really what the hardware token helps for.
>

This is why I don't get all the worrying about subkeys and expiration
and such.  A key is valid if it is in LDAP, and invalid otherwise.
Anything else is unnecessary complication at best, and a distraction.



-- 
Rich

Re: [gentoo-nfp] Developer Crypto Hardware (AGM)

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1286 bytes --]

On Wed, 2018-08-22 at 09:52 -0400, Rich Freeman wrote:
> On Wed, Aug 22, 2018 at 9:48 AM Kristian Fiskerstrand <k_f@gentoo.org> wrote:
> > 
> > On 08/22/2018 03:37 PM, Michał Górny wrote:
> > > This is one attack vector that -- AFAIU -- hardware tokens protect
> > > against.
> > 
> > Right, although it only shifts the attack, so user would just wait until
> > the token is available to perform whatever wanted anyways. In terms of
> > after the attack, the difference is we don't really use OpenPGP as a
> > long term identify such as it is in general. For a user, losing WoT etc
> > can have an impact, for Gentoo we just update LDAP and access is
> > effectively revoked without further issues, we don't need the key
> > material to survive this attack to be used after the fact again, which
> > is really what the hardware token helps for.
> > 
> 
> This is why I don't get all the worrying about subkeys and expiration
> and such.  A key is valid if it is in LDAP, and invalid otherwise.
> Anything else is unnecessary complication at best, and a distraction.
> 

I presume you're verifying my mail signatures against developer data
in LDAP.  Please let me know once all mail clients distributed in Gentoo
do that.

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: [gentoo-nfp] Developer Crypto Hardware (AGM)

[Rich Freeman]

On Wed, Aug 22, 2018 at 9:55 AM Michał Górny <mgorny@gentoo.org> wrote:
>
> On Wed, 2018-08-22 at 09:52 -0400, Rich Freeman wrote:
> > On Wed, Aug 22, 2018 at 9:48 AM Kristian Fiskerstrand <k_f@gentoo.org> wrote:
> > >
> > > On 08/22/2018 03:37 PM, Michał Górny wrote:
> > > > This is one attack vector that -- AFAIU -- hardware tokens protect
> > > > against.
> > >
> > > Right, although it only shifts the attack, so user would just wait until
> > > the token is available to perform whatever wanted anyways. In terms of
> > > after the attack, the difference is we don't really use OpenPGP as a
> > > long term identify such as it is in general. For a user, losing WoT etc
> > > can have an impact, for Gentoo we just update LDAP and access is
> > > effectively revoked without further issues, we don't need the key
> > > material to survive this attack to be used after the fact again, which
> > > is really what the hardware token helps for.
> > >
> >
> > This is why I don't get all the worrying about subkeys and expiration
> > and such.  A key is valid if it is in LDAP, and invalid otherwise.
> > Anything else is unnecessary complication at best, and a distraction.
> >
>
> I presume you're verifying my mail signatures against developer data
> in LDAP.  Please let me know once all mail clients distributed in Gentoo
> do that.

I don't verify email signatures at all.  Please let me know when gmail
supports this.  :)

But, if I cared about the integrity of emails I'd be a lot more
interested in whether the key used to sign the email is listed in LDAP
than whether it has a valid expiry date.  Anybody with the primary key
can change the expiry date, so an expiry date on a primary key is
meaningless.

-- 
Rich

Re: [gentoo-nfp] Developer Crypto Hardware (AGM)

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2125 bytes --]

On Wed, 2018-08-22 at 10:01 -0400, Rich Freeman wrote:
> On Wed, Aug 22, 2018 at 9:55 AM Michał Górny <mgorny@gentoo.org> wrote:
> > 
> > On Wed, 2018-08-22 at 09:52 -0400, Rich Freeman wrote:
> > > On Wed, Aug 22, 2018 at 9:48 AM Kristian Fiskerstrand <k_f@gentoo.org> wrote:
> > > > 
> > > > On 08/22/2018 03:37 PM, Michał Górny wrote:
> > > > > This is one attack vector that -- AFAIU -- hardware tokens protect
> > > > > against.
> > > > 
> > > > Right, although it only shifts the attack, so user would just wait until
> > > > the token is available to perform whatever wanted anyways. In terms of
> > > > after the attack, the difference is we don't really use OpenPGP as a
> > > > long term identify such as it is in general. For a user, losing WoT etc
> > > > can have an impact, for Gentoo we just update LDAP and access is
> > > > effectively revoked without further issues, we don't need the key
> > > > material to survive this attack to be used after the fact again, which
> > > > is really what the hardware token helps for.
> > > > 
> > > 
> > > This is why I don't get all the worrying about subkeys and expiration
> > > and such.  A key is valid if it is in LDAP, and invalid otherwise.
> > > Anything else is unnecessary complication at best, and a distraction.
> > > 
> > 
> > I presume you're verifying my mail signatures against developer data
> > in LDAP.  Please let me know once all mail clients distributed in Gentoo
> > do that.
> 
> I don't verify email signatures at all.  Please let me know when gmail
> supports this.  :)
> 
> But, if I cared about the integrity of emails I'd be a lot more
> interested in whether the key used to sign the email is listed in LDAP
> than whether it has a valid expiry date.  Anybody with the primary key
> can change the expiry date, so an expiry date on a primary key is
> meaningless.
> 

This only proves that you don't understand the purpose of expiration
dates at all and only makes assumptions that have nothing to do either
with reality or with the topic of this thread.

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: [gentoo-nfp] Developer Crypto Hardware (AGM)

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1003 bytes --]

On Wed, 2018-08-22 at 15:48 +0200, Kristian Fiskerstrand wrote:
> On 08/22/2018 03:37 PM, Michał Górny wrote:
> > This is one attack vector that -- AFAIU -- hardware tokens protect
> > against. 
> 
> Right, although it only shifts the attack, so user would just wait until
> the token is available to perform whatever wanted anyways. In terms of
> after the attack, the difference is we don't really use OpenPGP as a
> long term identify such as it is in general. For a user, losing WoT etc
> can have an impact, for Gentoo we just update LDAP and access is
> effectively revoked without further issues, we don't need the key
> material to survive this attack to be used after the fact again, which
> is really what the hardware token helps for.
> 

We're talking about 'the burglar can come into the house when the door
is unlocked' vs 'the burglar has the key and can come and go as he
pleases'.  You make it sound like there's no difference.

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: [gentoo-nfp] Developer Crypto Hardware (AGM)

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 1390 bytes --]

On 08/22/2018 04:06 PM, Michał Górny wrote:
> On Wed, 2018-08-22 at 15:48 +0200, Kristian Fiskerstrand wrote:
>> On 08/22/2018 03:37 PM, Michał Górny wrote:
>>> This is one attack vector that -- AFAIU -- hardware tokens protect
>>> against. 
>>
>> Right, although it only shifts the attack, so user would just wait until
>> the token is available to perform whatever wanted anyways. In terms of
>> after the attack, the difference is we don't really use OpenPGP as a
>> long term identify such as it is in general. For a user, losing WoT etc
>> can have an impact, for Gentoo we just update LDAP and access is
>> effectively revoked without further issues, we don't need the key
>> material to survive this attack to be used after the fact again, which
>> is really what the hardware token helps for.
>>
> 
> We're talking about 'the burglar can come into the house when the door
> is unlocked' vs 'the burglar has the key and can come and go as he
> pleases'.  You make it sound like there's no difference.
> 

If there is a trojan installed on the computer there isn't really much
difference between those scenarios; it really comes down to better
review platform a priori and more auditing of commits post hoc.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-nfp] Developer Crypto Hardware (AGM)

[Rich Freeman]

On Wed, Aug 22, 2018 at 10:04 AM Michał Górny <mgorny@gentoo.org> wrote:
>
> On Wed, 2018-08-22 at 10:01 -0400, Rich Freeman wrote:
> >
> > But, if I cared about the integrity of emails I'd be a lot more
> > interested in whether the key used to sign the email is listed in LDAP
> > than whether it has a valid expiry date.  Anybody with the primary key
> > can change the expiry date, so an expiry date on a primary key is
> > meaningless.
> >
>
> This only proves that you don't understand the purpose of expiration
> dates at all and only makes assumptions that have nothing to do either
> with reality or with the topic of this thread.
>

What value does an expiry on a primary key add in the context of singing things?

I'm not talking about encrypting things.  I'm talking about signing things.

If I can sign something with a primary key, I can change the
expiration date of the primary key so that it is valid on the date the
signature is made.

Now, I could see more of an argument for expiration on subkeys, or
with encryption, neither of which were the subject of my assertion
above.

I'm not sure how my email was any less on-topic than the one it was a
reply to, which talked about verifying signatures on emails, not
signing commits.

-- 
Rich

Re: [gentoo-nfp] Developer Crypto Hardware (AGM)

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2240 bytes --]

On Wed, 2018-08-22 at 16:29 +0200, Kristian Fiskerstrand wrote:
> On 08/22/2018 04:06 PM, Michał Górny wrote:
> > On Wed, 2018-08-22 at 15:48 +0200, Kristian Fiskerstrand wrote:
> > > On 08/22/2018 03:37 PM, Michał Górny wrote:
> > > > This is one attack vector that -- AFAIU -- hardware tokens protect
> > > > against. 
> > > 
> > > Right, although it only shifts the attack, so user would just wait until
> > > the token is available to perform whatever wanted anyways. In terms of
> > > after the attack, the difference is we don't really use OpenPGP as a
> > > long term identify such as it is in general. For a user, losing WoT etc
> > > can have an impact, for Gentoo we just update LDAP and access is
> > > effectively revoked without further issues, we don't need the key
> > > material to survive this attack to be used after the fact again, which
> > > is really what the hardware token helps for.
> > > 
> > 
> > We're talking about 'the burglar can come into the house when the door
> > is unlocked' vs 'the burglar has the key and can come and go as he
> > pleases'.  You make it sound like there's no difference.
> > 
> 
> If there is a trojan installed on the computer there isn't really much
> difference between those scenarios; it really comes down to better
> review platform a priori and more auditing of commits post hoc.
> 

I disagree.  There is a major difference.  I think we both agree that
by exercising the key, the attacker is risking discovery.

In scenario A, the attacker is capable of using the key only as long
as the malware is present.  At the same time, prolonged presence of
the malware increases chances of its discovery before the attacker
actually uses it.  So in the end, the attacker needs to act fast or he's
risking not being able to act at all.

In scenario B, the malware needs only to be present long enough to
acquire the key.  If the attacker is capable of removing it afterwards,
it is possible that the developer will never know he's been affected
until the attacker actually uses the cloned key.  This makes it possible
for the attacker to wait for the right moment, and therefore to cause
more damage.

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]