[dm-crypt] two factor authentication with zuluCrypt

[dm-crypt] two factor authentication with zuluCrypt

[.. ink ..]

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

I want to add the ability to create create and access volumes using two
factors, a passphrase and a key file. What is the best way to achieve this?

The simplest way to do it i can think of is to read the file and then append
the passphrase at the beginning, in the middle or at the end of it.

Will this be adequate? what is the best way to do this or is it a bad idea?

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

Re: [dm-crypt] two factor authentication with zuluCrypt

[Arno Wagner]

This will work, but it is not really 2-factor, as the key-file will 
not be "something you have". In fact, "something stored on disk" is
already done by LUKS, in the form of the salts and the key.

If you store part of the passphrase on an USB-Key, that may be
borderline 2-factor, but I doubt it really increases security.

Arno

On Sun, Oct 16, 2011 at 11:44:03PM -0400, .. ink .. wrote:
> I want to add the ability to create create and access volumes using two
> factors, a passphrase and a key file. What is the best way to achieve this?
> 
> The simplest way to do it i can think of is to read the file and then append
> the passphrase at the beginning, in the middle or at the end of it.
> 
> Will this be adequate? what is the best way to do this or is it a bad idea?

> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt


-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier 

Re: [dm-crypt] two factor authentication with zuluCrypt

[Milan Broz]

On 10/17/2011 05:44 AM, .. ink .. wrote:
> 
> I want to add the ability to create create and access volumes using
> two factors, a passphrase and a key file. What is the best way to
> achieve this?
> 
> The simplest way to do it i can think of is to read the file and then
> append the passphrase at the beginning, in the middle or at the end
> of it.
> 
> Will this be adequate? what is the best way to do this or is it a bad
> idea?

I do not think this increases security but Arno already mentioned this.
You can check various wrappers (in Debian for example) and integrate
support for smardcards etc.

But I would better to see that GUI does not implement these things,
this should be separate code.

Milan
p.s.

Btw there a lot of cleaning needed in your zulucrypt code.
It is not easy to package it - and without users in distros this make no sense.

For example your hardcoded "build" script should be replaced by qmake
(or whatever Qt world prefers today).

Another thing is loading of libcryptsetup through dlopen(). Not
only this will not work on other architectures (think /lib64) but
why you are doing this at all? There are versioned symbols,
you should link the program directly to library...
(Otherwise after upgrade in future this can do really bad things.)

...

There is great potential in some GUI similar to Truecrypt one
but your code is really not ready - don't you want better spent
time with cleaning the code?

Re: [dm-crypt] two factor authentication with zuluCrypt

[.. ink ..]

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

On Mo
>
>
> I do not think this increases security but Arno already mentioned this.
> You can check various wrappers (in Debian for example) and integrate
> support for smardcards etc.
>
> But I would better to see that GUI does not implement these things,
> this should be separate code.
>
> ok, will not then. It was just a though as i was looking at truecrypt to
see what features it has.

Why doesnt cryptsetup support two factor authentication?


>
> Btw there a lot of cleaning needed in your zulucrypt code.
> It is not easy to package it - and without users in distros this make no
> sense.
>
> For example your hardcoded "build" script should be replaced by qmake
> (or whatever Qt world prefers today).
>
> If you look at the code, i am sure you have seen it looked "amateurish".
Thats because this is my first attempt at meaningful programming and there
is a lot to cover. I started with cryptsetup   because i manage a bunch of
encrypted volumes in files and managing them through a cli interface was
annoying, i created a script to simply the task but it still involved
opening a terminal and typing commands and it got really boring really
fast.

That is why i started this project with two requirements, it has to work
without requiring root's  password(suid program) and it must work with
encrypted files, of type "plain" because thats what we have mostly. It
already does what i want, i am working on it further to  learn more and make
cryptsetup easier to use for others too.

packaging is something i was going to do next and i currently do not know
anything about them, the script was a quick hack to build the package and
install it while i concentrate on learning and doing other things. If
packaging can not work with it, then i will change it to use qmake for
everything.



> Another thing is loading of libcryptsetup through dlopen(). Not
> only this will not work on other architectures (think /lib64)


Can you clarify on this? it will not work because dlopen isnt present/works
differently in 64 bit or because the search path in my code does not include
/lib64?


> but
> why you are doing this at all? There are versioned symbols,
> you should link the program directly to library...
> (Otherwise after upgrade in future this can do really bad things.)
>

because this is my first attempt at meaning programming and i am creating an
suid program without really comprehending a lot of what i am doing and suid
program in linux are practically considered a sin, was just trying to cover
my bases by being as specific as i can. I though going straight and manually
picking a library will be more secure. Will go back to linking directly.
Thanks for the input.

I could have statically link against the library but pclinuxos does not ship
with the static library,  cryptsetup only build it on request at build time
and i though other distros also do not ship with the static library and this
could inconvenience users and thats why i went with the shared library.


>
> There is great potential in some GUI similar to Truecrypt one
> but your code is really not ready - don't you want better spent
> time with cleaning the code?
>

i try to clean it as much as i can. If there is anything more you can think
that needs cleaning, please tell and i will do it.

While we are talking about cleaning the code, from what i know so far,
"mount/umount" system calls do not add entries in "/etc/mtab" and tools like
kdiskfree do not show these opened volumes if they do not have entries in
mtab, manually editing the file corrupts it and that is why i use
"mount/umount" cli tools through popen because they do whatever they to do
add entries in mtab on mounting and unmounting volumes.

Can you think of a way i can do this completely within my program without
corrupting the file? manually editing mtab will cause mount/umount command
to hand and then they complain about unlocked /etc/mtab~ or something.

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

Re: [dm-crypt] two factor authentication with zuluCrypt

[Milan Broz]

On 10/17/2011 04:39 PM, .. ink .. wrote:
> Why doesnt cryptsetup support two factor authentication?

I like the Unix approach - one simple program, one function.

cryptsetup is nothing more than low-level configuration
for dmcrypt and on-disk metadata (key management) wrapper.
And provides library covering that.

You can build various plugins (see e.g. how pam_mount
or systemd uses libcryptsetup) but I would like to cryptsetup
remains simple utility just for this exact task.

(But maybe we should add various wrappers to code tree later.)

> That is why i started this project with two requirements, it has to
> work without requiring root's  password(suid program) and it must
> work with encrypted files, of type "plain" because thats what we have
> mostly. It already does what i want, i am working on it further to
> learn more and make cryptsetup easier to use for others too.

That's fine. Just now it is time to do it properly if you want
others to use it;-)

> Can you clarify on this? it will not work because dlopen isnt
> present/works differently in 64 bit or because the search path in my
> code does not include /lib64?

Just use it as shared library and use libcryptsetup.h, see for example
docs/examples in cryptsetup source tree. (Btw if you need more examples,
just tell me, we can add something there for reference.)


> but why you are doing this at all? There are versioned symbols, you
> should link the program directly to library... (Otherwise after
> upgrade in future this can do really bad things.)
> 
> 
> because this is my first attempt at meaning programming and i am
> creating an suid program without really comprehending a lot of what i
> am doing and suid program in linux are practically considered a sin,
> was just trying to cover my bases by being as specific as i can. I
> though going straight and manually picking a library will be more
> secure. Will go back to linking directly. Thanks for the input.

Currently libcryptsetup is designed to run root-only.
(The main reason is that device-mapper in kernel require root
capability for all operations. I hope this will change in future
and user will be able to create private devices without requiring
root privilege - but we are not there yet.)

> I could have statically link against the library but pclinuxos does
> not ship with the static library,  cryptsetup only build it on
> request at build time and i though other distros also do not ship
> with the static library and this could inconvenience users and thats
> why i went with the shared library.

Avoid static libraries if possible. (If done properly, it can be
more secure but usually it is security disaster - usually nobody cares
about properly rebuilding all dependencies if problem is found.
Most of recent generic distros are using dynamic libraries only.)

Or better (but I think it is not good idea for GUI) - provide option
to link statically.

> While we are talking about cleaning the code, from what i know so
> far, "mount/umount" system calls do not add entries in "/etc/mtab"
> and tools like kdiskfree do not show these opened volumes if they do
> not have entries in mtab, manually editing the file corrupts it and
> that is why i use "mount/umount" cli tools through popen because they
> do whatever they to do add entries in mtab on mounting and unmounting
> volumes.

/etc/mtab is on many systems just link to /proc/mounts, you cannot edit
it directly.

What exactly you are trying to do? mount/kernel should handle this file.

And mounted fs is not the only possible user of LUKS volume, you can have
mapped LVM volumes over it, MD raid, loopback, partition, ....

Milan

Re: [dm-crypt] two factor authentication with zuluCrypt

[Arno Wagner]

On Mon, Oct 17, 2011 at 05:47:31PM +0200, Milan Broz wrote:
> On 10/17/2011 04:39 PM, .. ink .. wrote:
> > Why doesnt cryptsetup support two factor authentication?
> 
> I like the Unix approach - one simple program, one function.

The thing is that you cannot do 2-factor authentication 
generically. You typically have password/passphrase as
one factor, and that can be done generically and is implemented
in cryptsetup. However the second factor is usually a token
or biometrics and there is no way to do these generically. 
They always have to be customized to the concrete solution.
While there are generic smarcard indterfaces, they are
still problematic for this use.

I think the present approach is prefectly fine. It is also easy 
to script in a concrete token or biometrics, just use a longer
passphrase and split it, as originally suggested. Or use
the library, although that does not provide a conceptyal
security increase as compared to scripting.

> cryptsetup is nothing more than low-level configuration
> for dmcrypt and on-disk metadata (key management) wrapper.
> And provides library covering that.
> 
> You can build various plugins (see e.g. how pam_mount
> or systemd uses libcryptsetup) but I would like to cryptsetup
> remains simple utility just for this exact task.
> 
> (But maybe we should add various wrappers to code tree later.)

I can see that happening, e.g. as soon as there is a stable token 
standard with working multi-vendor support. Or if, for example, 
there is a widely-adopted standard for a smartphone to prove its
presence (misusing a phone as a token).

Arno
-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier 

Re: [dm-crypt] two factor authentication with zuluCrypt

[.. ink ..]

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

>
>
>
> The thing is that you cannot do 2-factor authentication
> generically. You typically have password/passphrase as
> one factor, and that can be done generically and is implemented
> in cryptsetup. However the second factor is usually a token
> or biometrics and there is no way to do these generically.
> They always have to be customized to the concrete solution.
> While there are generic smarcard indterfaces, they are
> still problematic for this use.
>
>
ok, thanks for the info.

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

Re: [dm-crypt] two factor authentication with zuluCrypt

[.. ink ..]

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

>
>
> Just use it as shared library and use libcryptsetup.h, see for example
> docs/examples in cryptsetup source tree. (Btw if you need more examples,
> just tell me, we can add something there for reference.)
>
> I looked at the example in the just released beta and i now understand the
API and can work with it with no problems. My program now does interface
with cryptsetup using only the library.

Just to clarify, just linking against the library and let link loader look
up and load it at runtime poses no security issue to an suid program? The
reason why i manually load the library at run time and pollute the code with
all those pointers was to avoid security issues i couldnt think of.

Or better (but I think it is not good idea for GUI) - provide option
> to link statically.
>
>
My program is divided into two parts, the GUI part(zuluCrypt)  runs with
normal user's privileges and calls the cli backend(zuluCrpt-cli) to actually
do the work. The cli backend is the one that runs with suid bit set and
interfaces with cryptsetup

You mentioned "cleaning up the code" with two examples, dynamically linking
the library(will do that) and use proper "industry standard" tools for
building and installation(will do that). Anything else that needs cleaning?

Thanks for taking your time to look into it.

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