mirror of
https://github.com/hak5/wifipineapple-openwrt.git
synced 2025-10-29 16:57:19 +00:00
add the 'ead' package (emergency access daemon),
which can provide remote access to your device, even if the ip and firewall settings are broken git-svn-id: svn://svn.openwrt.org/openwrt/trunk@13738 3c298f89-4303-0410-b956-a3cf2f4a3e73
This commit is contained in:
110
package/ead/src/tinysrp/Notes
Normal file
110
package/ead/src/tinysrp/Notes
Normal file
@@ -0,0 +1,110 @@
|
||||
t_* stuff is from the srp 1.7.1 dist
|
||||
bn_* stuff is from openssl 0.9.6
|
||||
|
||||
(The 7 in libtinysrp's version number reflects the srp version.)
|
||||
|
||||
Licensing and copyright for srp and openssl are as indicated in the relevant
|
||||
source files. Everything else here is GPL, including the tinysrp protocol.
|
||||
|
||||
Changelog since initial release:
|
||||
|
||||
0.7.4 more robust terminal modes in t_getpass
|
||||
a potential buffer overflow in tinysrp
|
||||
0.7.5 uninitialized pointer bug in tconf
|
||||
|
||||
Changes from the base srp and openssl distributions:
|
||||
|
||||
I've removed everything that's not needed for client/server operations, and
|
||||
all the bn_* stuff that's only used for prime generation has been moved to
|
||||
t_conf.c, which isn't part of the library anymore. Also, all the routines
|
||||
used for passphrase file maintenance have been moved to tphrase.c.
|
||||
|
||||
The library has been optimized (a bit) for space instead of speed. Since
|
||||
authentication is usually only done once, this isn't a big problem. Modern
|
||||
CPUs are plenty fast for this task, and even 100 MHz CPUs are fine. If you
|
||||
really need the speed, get the regular distributions.
|
||||
|
||||
Note that if the server sends the client a prime that the client doesn't
|
||||
know about, the client MUST test for primality. Since this is pretty
|
||||
expensive, and takes 30 seconds on a 100 MHz machine, and uses lots of code,
|
||||
I've removed that ability from the client. So only KNOWN primes can be
|
||||
used. You can still generate new ones with tconf, but you have to install
|
||||
them in the table of known primes (pre_params) in t_getconf.c that's common
|
||||
to the client and server, and recompile. The configuration file is gone.
|
||||
|
||||
The default prime (the last entry in the table) is 1024 bits; there are
|
||||
others with more bits but they will be correspondingly slower.
|
||||
|
||||
The default tpasswd file (which is an ascii file that may be editted with a
|
||||
regular text editor) contains two users: moo (passphrase "glub glub") and
|
||||
"new user" (passphrase "this is a test"). Passphrases may be added or
|
||||
changed with tphrase; you can also change the user's prime. To delete a
|
||||
user, edit the tpasswd file and remove that line. The tpasswd file's
|
||||
default name is DEFAULT_PASSWD in t_pwd.h. Note that you can't change a
|
||||
user's username by editting the file: the username is encoded in the
|
||||
verifier. If you change a username you must set a new passphrase with
|
||||
tphrase.
|
||||
|
||||
Here is an example session, using the supplied srvtest and clitest. First,
|
||||
start both programs in different windows, and enter the user names. Normally,
|
||||
the client would send the username to the server. Server lines are marked
|
||||
with S>, client lines with C>.
|
||||
|
||||
S> % srvtest
|
||||
S> Enter username: moo
|
||||
S> index (to client): 5
|
||||
S> salt (to client): 19AI0Hc9jEkdFc
|
||||
|
||||
C> % clitest
|
||||
C> Enter username: moo
|
||||
C> Enter index (from server): 5
|
||||
C> Enter salt (from server): 19AI0Hc9jEkdFc
|
||||
|
||||
The server reports the index and salt values used for that user. They
|
||||
are sent over the network to the client. (Simulate this by cutting and
|
||||
pasting from one window to the other.)
|
||||
|
||||
C> A (to server): 5wCDXRxLIv/zLazYfKupV/OY3BlhTZuJ71wVgI0HcL1kSJEpkMuWF.xEz/BV2wlJl7vk5Eoz9KMS1ccnaatsVP5D6CBm7UA.yVB59EQFN0dNBirvX29NAFdtdMsMppo5tHRy987XjJWrWSLpeibq6emr.gP8nYyX75GQqSiMY1j
|
||||
C> Enter password:
|
||||
|
||||
S> Enter A (from client): 5wCDXRxLIv/zLazYfKupV/OY3BlhTZuJ71wVgI0HcL1kSJEpkMuWF.xEz/BV2wlJl7vk5Eoz9KMS1ccnaatsVP5D6CBm7UA.yVB59EQFN0dNBirvX29NAFdtdMsMppo5tHRy987XjJWrWSLpeibq6emr.gP8nYyX75GQqSiMY1j
|
||||
|
||||
Now the client calculates A and sends it to the server, and while the
|
||||
server is munching on that, the client gets the password from the user.
|
||||
|
||||
S> B (to client): 9dcCpulxQAbaDXI0NHWY6B.QH6B9fsoXs/x/5SCNBNJm/6H6bYfbVrwNmdquhLZjYMvpcgGc2mBYqL77RNfw1kVQo17//GfsByECBIjRnrAn02ffX9Y/llJcfscAQiii0hyZhJf9PT5wE7pC7WUjIgSqckIZ0JLNDbSr7fJcrgw
|
||||
S> Session key: ebbcf3a45c968defdcfff6e144ad8d4f5412167c9716e79cbf7cacfe18257947ad46fa5d6418a1fd
|
||||
|
||||
The server now calculates B and sends it to the client. The session key
|
||||
is not sent -- it is a shared secret that can be used for encryption.
|
||||
|
||||
C> Enter B (from server): 9dcCpulxQAbaDXI0NHWY6B.QH6B9fsoXs/x/5SCNBNJm/6H6bYfbVrwNmdquhLZjYMvpcgGc2mBYqL77RNfw1kVQo17//GfsByECBIjRnrAn02ffX9Y/llJcfscAQiii0hyZhJf9PT5wE7pC7WUjIgSqckIZ0JLNDbSr7fJcrgw
|
||||
C> Session key: ebbcf3a45c968defdcfff6e144ad8d4f5412167c9716e79cbf7cacfe18257947ad46fa5d6418a1fd
|
||||
C> Response (to server): b9ea99094a176c4be28eb469982066cc7146d180
|
||||
|
||||
The client uses the B value to calculate its own copy of the shared secret
|
||||
session key, and sends a response to the server proving that it does know
|
||||
the correct key.
|
||||
|
||||
S> Enter response (from client): b9ea99094a176c4be28eb469982066cc7146d180
|
||||
S> Authentication successful.
|
||||
S> Response (to client): cd46c839ccad2d0c76f3ca1905ae8ceda8d1c1dc
|
||||
|
||||
The server authenticates the client. (You're in!)
|
||||
|
||||
C> Enter server response: cd46c839ccad2d0c76f3ca1905ae8ceda8d1c1dc
|
||||
C> Server authentication successful.
|
||||
|
||||
The client authenticates the server (prevents server spoofing in the case
|
||||
where the session key isn't used to encrypt the channel -- a spoofed server
|
||||
might just respond with random values and _pretend_ to authenticate the
|
||||
client; but the spoofed server won't know the session key and this check
|
||||
catches that).
|
||||
|
||||
Final note:
|
||||
|
||||
Remember that many breaches of security involve buggy software, such as
|
||||
servers susceptible to buffer overflow exploits that totally bypass any
|
||||
passphrase, secure or not. If an attacker roots your client, or the server,
|
||||
no form of authentication will work. Consider MAC-based schemes if this
|
||||
worries you.
|
||||
Reference in New Issue
Block a user