From 4641b9d435158ecbec0be46b23d2267a5dbfedca Mon Sep 17 00:00:00 2001 From: shanedk Date: Sat, 17 Feb 2018 18:04:47 -0500 Subject: [PATCH 1/8] Added User Best Practices --- src/draft-sqrl.xml | 95 +++++++++++++++++++++++++++++++++++++++++----- 1 file changed, 86 insertions(+), 9 deletions(-) diff --git a/src/draft-sqrl.xml b/src/draft-sqrl.xml index 5d73282..29d04d5 100644 --- a/src/draft-sqrl.xml +++ b/src/draft-sqrl.xml @@ -45,12 +45,12 @@ they will automatically be output with "(if approved)" -->Secure Quick Reliable Login (SQRL), an Authentication and Identity Management Framework
adam@novators.net
GeneralInternet Engineering Task ForceGeneralInternet Engineering Task Forcesqrl &RFC2104; &RFC2119; - &RFC2898; + &RFC2898; &RFC3548; &RFC3986; &RFC7914; @@ -446,7 +501,29 @@ VUK = ed25519_public_key( curve25519_key_agreement( ILK, RLK ));]]>Secure Hash StandardNational Institute of Standards and Technology NIST Special Publication 800-38D: Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC.U.S. National Institute of Standards and Technology - + How to share a secret &RFC4868; -
TODO
TODO
Secure cryptographic systems depend on the ability to create quality random numbers, and SQRL is no different in this regard. SQRL's needs are meager compared to many other functions and protocols, but critical.The use of a pseudo-random function to generate random numbers is only as good as the entropy it is seeded with. As RFC4086 points out, a hacker may find it easier to reproduce the environment a PRF was running in when it produced the secret quantities than to make blind guesses through the search space. [RFC4086]Optimally, the numbers used for seeding cryptographic functions such as Curve25519 should be truly random, but what constitutes "truly random" is regarded as much philosophy as computer science. However, a good working definition of "truly random" is one where the amount of entropy in a number is equal to its length; e.g., a 256-bit number that contains 256 bits of entropy.Unfortunately, determining the amount of entropy in an information stream is tricky at best. But entropy is never reduced as more information is added; even weak sources of entropy, when added together, can produce sufficient entropy. For that reason, none of the data collected during entropy harvesting should be discarded.The method recommended by SQRL is to harvest as much entropy as possible from as many uncorrelated sources as possible in the time available, and run the data stream through SHA-256 or SHA-512, depending on how much randomness is needed. The Secure Hashing Algorithm should change half the bits of the output when just a single bit of the input is changed, so the entropy should be preserved up to the length of the resulting hash. The technique, then, is to hash an amount of data where the entropy content almost certainly far exceeds 256 or 512 bits. These amounts are fairly trivial.For more about entropy harvesting, see RFC4086.
Sources of entropy vary greatly depending on the hardware, operating system, and other aspects of the client device.
All operating systems have a source of randomness available (e.g., /dev/random on UNIX-like systems), but developers should think twice before relying solely on these. Flaws and backdoors could result in a false sense of security. For example, in 2013 a flaw in Android's SecureRandom function made wallets generated on those devices vulnerable to remote hacking and the theft of funds, even without access to the device. See Klyubin, Alex, "Some SecureRandom Thoughts," Android Developers Blog, 14 August 2013.Developers should also be advised that many of these use some of the same techniques described below, meaning that utilizing the same technique might not result in as much entropy as estimated.
Hardware sources can be very effective at harvesting entropy, but care must be taken to make sure that they exist on a particular implementation, and that the hardware hasn't failed in some way.The system clock has traditionally been used as a source of randomness, although it must be considered that users are more likely to generate the random numbers at some times of the day than others. Subseconds provide the greatest entropy here.Some systems come with embedded hardware that produce noise specifically for the purpose of seeding PRFs.Wireless networking devices can be polled for signal strength and other data.Processor statistics can be a significant source, such as cache hits/misses and other low-level system counters, voltage, fan speed, and thermal data.Sound from a microphone could be a source of high-quality entropy in a typical room with air conditioning, fans, and other source of noise, as well as interference on the sound channel. In such a case, a fraction of a second--less than two hundredths--would be sufficient, but as there is no guarantee longer periods should be considered.One or two frames from a camera can likewise be a source of high-entropy noise because of the sensor, which is especially the case if the SQRL client can set the camera's ISO to a high number. Most cell phones in particular have cameras that generate sufficient noise in the low-order bits. A single 640x480 frame would likely be sufficient for SQRL's purposes. Care must be taken to ensure the client is getting the raw camera data, not compressed data which may have much of the noise removed.Free bytes of memory and storage space can vary quite a bit, adding a not insignificant amount of entropy.Network statistics, such as packet arrival time, can be effective, but only if it can be ensured that these are not subject to manipulation.
The user can provide a good measure of entropy, either directly by the client engaging the user, or indirectly.Examining mouse movements or keyboard strokes can be a source of entropy, although how much is a matter of some debate.Accelerometer data on cell phones and other such devices can pick up minute movements of the user's hand, even if the user is trying to hold it steady.
 + +
+
+ Disclaimer: None of this is intended to be any sort of legal advice, or indeed any guarantee that problems involving SQRL clients and identities will be minimized. They are designed to apply to most SQRL users in most situations most of the time. It should be up to each individual's discretion to determine whether or not particular recommendations make sense to their situation. +
+ Traditionally, security experts have advised having unique passwords for every resource. The reason why is so that one resource being compromised will not threaten others. However, in the case of a single SQRL identity copied to multiple devices, a compromise of any of these identities would give an attacker full access to all SQRL-enabled logins, so the user gains nothing from protecting his SQRL identity on different devices with different passwords. But when users are asked to create different passwords, they generally pick weaker, formulaic passwords that are easier to remember. + For this reason, it makes sense to have a single strong password protecting all copies of the user's SQRL identity. +
+
+ It is crucial that the user not lose his or her identity, as that would lock him out of any and all needed resources. Keeping a secure backup is essential. + SQRL clients do not distinguish between exporting and backing up an identity, whether done by file, QR code, or text. But conceptually, exporting an identity is done with the intent to import it into another client in a timely manner. Therefore, exporting generally includes the identity encrypted with the Master Password. + Backups, on the other hand, are intended for longer-term storage. The encryption on them therefore needs to be more secure than perhaps will be the case with the user's Master Password, which may be forgotten in the interim anyway. Therefore, when making a backup of an identity, it should be made without the Master Password, containing only a copy of the encrypted IUK from which the identity can be regenerated. The user would therefore need the Rescue Code to restore the backup. + Note that text backup MUST NOT be exported without the Master Password. +
+
+ A user putting together his Last Will and Testament will want the executor(s) of his estate to be able to easily access all important assets. Since probate attorneys consider the security of all of this information to be paramount, it is recommended that they be given a hard copy of the SQRL client, exported without password, using the "data entry" method. The Rescue Code must also be included. The information must be updated whenever the user creates a new SQRL identity or re-keys an existing one. + If the use of a probate attorney isn't desirable (e.g., the user lives in a country with no recognition of attorney-client privilege), SQRL's "data entry" export and the associated Rescue Code could be distributed through the person's heirs via Shamir's Secret Sharing. +
+
+
TODO
+
TODO
+
+
Secure cryptographic systems depend on the ability to create quality random numbers, and SQRL is no different in this regard. SQRL's needs are meager compared to many other functions and protocols, but critical.The use of a pseudo-random function to generate random numbers is only as good as the entropy it is seeded with. As RFC4086 points out, a hacker may find it easier to reproduce the environment a PRF was running in when it produced the secret quantities than to make blind guesses through the search space. [RFC4086]Optimally, the numbers used for seeding cryptographic functions such as Curve25519 should be truly random, but what constitutes "truly random" is regarded as much philosophy as computer science. However, a good working definition of "truly random" is one where the amount of entropy in a number is equal to its length; e.g., a 256-bit number that contains 256 bits of entropy.Unfortunately, determining the amount of entropy in an information stream is tricky at best. But entropy is never reduced as more information is added; even weak sources of entropy, when added together, can produce sufficient entropy. For that reason, none of the data collected during entropy harvesting should be discarded.The method recommended by SQRL is to harvest as much entropy as possible from as many uncorrelated sources as possible in the time available, and run the data stream through SHA-256 or SHA-512, depending on how much randomness is needed. The Secure Hashing Algorithm should change half the bits of the output when just a single bit of the input is changed, so the entropy should be preserved up to the length of the resulting hash. The technique, then, is to hash an amount of data where the entropy content almost certainly far exceeds 256 or 512 bits. These amounts are fairly trivial.For more about entropy harvesting, see RFC4086.
Sources of entropy vary greatly depending on the hardware, operating system, and other aspects of the client device.
All operating systems have a source of randomness available (e.g., /dev/random on UNIX-like systems), but developers should think twice before relying solely on these. Flaws and backdoors could result in a false sense of security. For example, in 2013 a flaw in Android's SecureRandom function made wallets generated on those devices vulnerable to remote hacking and the theft of funds, even without access to the device. See Klyubin, Alex, "Some SecureRandom Thoughts," Android Developers Blog, 14 August 2013.Developers should also be advised that many of these use some of the same techniques described below, meaning that utilizing the same technique might not result in as much entropy as estimated.
Hardware sources can be very effective at harvesting entropy, but care must be taken to make sure that they exist on a particular implementation, and that the hardware hasn't failed in some way.The system clock has traditionally been used as a source of randomness, although it must be considered that users are more likely to generate the random numbers at some times of the day than others. Subseconds provide the greatest entropy here.Some systems come with embedded hardware that produce noise specifically for the purpose of seeding PRFs.Wireless networking devices can be polled for signal strength and other data.Processor statistics can be a significant source, such as cache hits/misses and other low-level system counters, voltage, fan speed, and thermal data.Sound from a microphone could be a source of high-quality entropy in a typical room with air conditioning, fans, and other source of noise, as well as interference on the sound channel. In such a case, a fraction of a second--less than two hundredths--would be sufficient, but as there is no guarantee longer periods should be considered.One or two frames from a camera can likewise be a source of high-entropy noise because of the sensor, which is especially the case if the SQRL client can set the camera's ISO to a high number. Most cell phones in particular have cameras that generate sufficient noise in the low-order bits. A single 640x480 frame would likely be sufficient for SQRL's purposes. Care must be taken to ensure the client is getting the raw camera data, not compressed data which may have much of the noise removed.Free bytes of memory and storage space can vary quite a bit, adding a not insignificant amount of entropy.Network statistics, such as packet arrival time, can be effective, but only if it can be ensured that these are not subject to manipulation.
The user can provide a good measure of entropy, either directly by the client engaging the user, or indirectly.Examining mouse movements or keyboard strokes can be a source of entropy, although how much is a matter of some debate.Accelerometer data on cell phones and other such devices can pick up minute movements of the user's hand, even if the user is trying to hold it steady.
 From 74f8d2109e34dcd0c113354f0b32542c2c87b5a3 Mon Sep 17 00:00:00 2001 From: shanedk Date: Sun, 18 Feb 2018 07:47:25 -0500 Subject: [PATCH 2/8] Fixed outline --- src/draft-sqrl.xml | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/src/draft-sqrl.xml b/src/draft-sqrl.xml index 29d04d5..63c1816 100644 --- a/src/draft-sqrl.xml +++ b/src/draft-sqrl.xml @@ -505,8 +505,10 @@ VUK = ed25519_public_key( curve25519_key_agreement( ILK, RLK ));]]> &RFC4868; -
-
+
+
TODO
+
TODO
+
Disclaimer: None of this is intended to be any sort of legal advice, or indeed any guarantee that problems involving SQRL clients and identities will be minimized. They are designed to apply to most SQRL users in most situations most of the time. It should be up to each individual's discretion to determine whether or not particular recommendations make sense to their situation.
Traditionally, security experts have advised having unique passwords for every resource. The reason why is so that one resource being compromised will not threaten others. However, in the case of a single SQRL identity copied to multiple devices, a compromise of any of these identities would give an attacker full access to all SQRL-enabled logins, so the user gains nothing from protecting his SQRL identity on different devices with different passwords. But when users are asked to create different passwords, they generally pick weaker, formulaic passwords that are easier to remember. @@ -523,7 +525,6 @@ VUK = ed25519_public_key( curve25519_key_agreement( ILK, RLK ));]]>If the use of a probate attorney isn't desirable (e.g., the user lives in a country with no recognition of attorney-client privilege), SQRL's "data entry" export and the associated Rescue Code could be distributed through the person's heirs via Shamir's Secret Sharing.
-
TODO
-
TODO
+
Secure cryptographic systems depend on the ability to create quality random numbers, and SQRL is no different in this regard. SQRL's needs are meager compared to many other functions and protocols, but critical.The use of a pseudo-random function to generate random numbers is only as good as the entropy it is seeded with. As RFC4086 points out, a hacker may find it easier to reproduce the environment a PRF was running in when it produced the secret quantities than to make blind guesses through the search space. [RFC4086]Optimally, the numbers used for seeding cryptographic functions such as Curve25519 should be truly random, but what constitutes "truly random" is regarded as much philosophy as computer science. However, a good working definition of "truly random" is one where the amount of entropy in a number is equal to its length; e.g., a 256-bit number that contains 256 bits of entropy.Unfortunately, determining the amount of entropy in an information stream is tricky at best. But entropy is never reduced as more information is added; even weak sources of entropy, when added together, can produce sufficient entropy. For that reason, none of the data collected during entropy harvesting should be discarded.The method recommended by SQRL is to harvest as much entropy as possible from as many uncorrelated sources as possible in the time available, and run the data stream through SHA-256 or SHA-512, depending on how much randomness is needed. The Secure Hashing Algorithm should change half the bits of the output when just a single bit of the input is changed, so the entropy should be preserved up to the length of the resulting hash. The technique, then, is to hash an amount of data where the entropy content almost certainly far exceeds 256 or 512 bits. These amounts are fairly trivial.For more about entropy harvesting, see RFC4086.
Sources of entropy vary greatly depending on the hardware, operating system, and other aspects of the client device.
All operating systems have a source of randomness available (e.g., /dev/random on UNIX-like systems), but developers should think twice before relying solely on these. Flaws and backdoors could result in a false sense of security. For example, in 2013 a flaw in Android's SecureRandom function made wallets generated on those devices vulnerable to remote hacking and the theft of funds, even without access to the device. See Klyubin, Alex, "Some SecureRandom Thoughts," Android Developers Blog, 14 August 2013.Developers should also be advised that many of these use some of the same techniques described below, meaning that utilizing the same technique might not result in as much entropy as estimated.
Hardware sources can be very effective at harvesting entropy, but care must be taken to make sure that they exist on a particular implementation, and that the hardware hasn't failed in some way.The system clock has traditionally been used as a source of randomness, although it must be considered that users are more likely to generate the random numbers at some times of the day than others. Subseconds provide the greatest entropy here.Some systems come with embedded hardware that produce noise specifically for the purpose of seeding PRFs.Wireless networking devices can be polled for signal strength and other data.Processor statistics can be a significant source, such as cache hits/misses and other low-level system counters, voltage, fan speed, and thermal data.Sound from a microphone could be a source of high-quality entropy in a typical room with air conditioning, fans, and other source of noise, as well as interference on the sound channel. In such a case, a fraction of a second--less than two hundredths--would be sufficient, but as there is no guarantee longer periods should be considered.One or two frames from a camera can likewise be a source of high-entropy noise because of the sensor, which is especially the case if the SQRL client can set the camera's ISO to a high number. Most cell phones in particular have cameras that generate sufficient noise in the low-order bits. A single 640x480 frame would likely be sufficient for SQRL's purposes. Care must be taken to ensure the client is getting the raw camera data, not compressed data which may have much of the noise removed.Free bytes of memory and storage space can vary quite a bit, adding a not insignificant amount of entropy.Network statistics, such as packet arrival time, can be effective, but only if it can be ensured that these are not subject to manipulation.
The user can provide a good measure of entropy, either directly by the client engaging the user, or indirectly.Examining mouse movements or keyboard strokes can be a source of entropy, although how much is a matter of some debate.Accelerometer data on cell phones and other such devices can pick up minute movements of the user's hand, even if the user is trying to hold it steady.
From 9209276b296cd3a8089fd24c8713997a637a5a42 Mon Sep 17 00:00:00 2001 From: shanedk Date: Sun, 18 Feb 2018 08:20:34 -0500 Subject: [PATCH 3/8] Added my authorship --- src/draft-sqrl.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/draft-sqrl.xml b/src/draft-sqrl.xml index d7dde29..264c83a 100644 --- a/src/draft-sqrl.xml +++ b/src/draft-sqrl.xml @@ -43,7 +43,7 @@ ipr values: full3667, noModification3667, noDerivatives3667 you can add the attributes updates="NNNN" and obsoletes="NNNN" they will automatically be output with "(if approved)" -->Secure Quick Reliable Login (SQRL), an Authentication and Identity Management Framework
adam@novators.net
Secure Quick Reliable Login (SQRL), an Authentication and Identity Management Framework
adam@novators.net
shane@shanekillian.org