# DMcrypt not using key file to decrypt drive on boot.

## finalturismo

update 10/6/2020

ok so i found out what i was doing wrong, i had the decryption key located on the encrypted partition.

Simply not possible to access the decryption key prior to decrypting the drive, not sure what i was thinking. 

So i see on the custom Initramfs section of the Gentoo tutorials area that IT IS possible to build in the Cryptsetup directly into Initramfs.

Now i just need to figure out how to built the keyfile into initramfs before compiling it with genkernel.

I REALLY need to get this done. This way when the customer gets the wiping system they are only able to use it and if there is a smart tech anywhere near even if they put the drive into a docking station they wont be able to decrypt the drive.

This also protects they key file on the boot partition as it is built into the initramfs directly.

Also the end user will not be able to gain any type of root access to the system as they would need the password to be able to login to the shell.  I thought this would be a simple process until i came to this part XD

So anyway... how do i build the key file into the initramfs?  :Smile: 

i know your out there somewhere just click my post please 0.o

------------------------------OLD ORIGINAL POST--------------------------

So guys i encrypted my drive for the drive wiping software we are in the middle of beta testing.

These drives are to be sent out to a few companies so they can beta test the disk wiping software we made. 

The problem i am having is that, dmcrypt is not auto unlocking the drive on boot with the key specified in /etc/keyfiles/main.key. 

Now to be clear iam not having an issue decrypting the drive, iam just having an issue using the auto unlock feature when using the main.key file to unlock at startup.

I cant see what iam doing wrong.

Problem statements

1. Dmcrypt is asking for unlock password on boot

2. Key file and UUID is correctly stored in /etc/conf.d/dmcrypt

3. Confirmed key added to luks slots. 

4. dmcrypt has been added to boot init (rc-update add dmcrypt boot)

Configuration Information

lsblk -F output

```
NAME     FSTYPE      FSVER LABEL UUID                                 FSAVAIL FSUSE% MOUNTPOINT

sda

|-sda1

|-sda2   vfat                    D3B3-7C11                             455.6M    11% /boot

|-sda3   swap                    d136f985-79ca-4d54-bbfa-4b2479003d52                [SWAP]

`-sda4   crypto_LUKS             9752e262-8810-4e10-869b-c3d1f0464128

  `-root ext4                    fb10e39f-8e52-44cd-9b18-ebeb36513d2f   43.1G    41% /

sr0
```

dmcrypt entry 

```
target=root

source=UUID=9752e262-8810-4e10-869b-c3d1f0464128

key=/etc/keyfiles/main.key
```

/etc/fstab entry

Iam using parameter in /etc/default/grub if you are wondering why i dont have the root fs set here. 

```
#BOOT

UUID="D3B3-7C11"             /boot               vfat           defaults                  0 0

#swap

UUID="d136f985-79ca-4d54-bbfa-4b2479003d52"     none    swap     sw         0 0
```

/etc/default/grub    entry

Do i need to specify the key file location in kernel parameter at all?

```

GRUB_CMDLINE_LINUX="crypt_root=UUID=9752e262-8810-4e10-869b-c3d1f0464128 root=/dev/mapper/root fbcon=scrollback:10000k"
```

cryptsetup luksDump /dev/sda4

Edited some stuff to hide some of the hex entries for privacy reasons. 

```
AUTODISK ~ # cryptsetup luksDump /dev/sda4

LUKS header information

Version:        2

Epoch:          12

Metadata area:  16384 [bytes]

Keyslots area:  16744448 [bytes]

UUID:           9752e262-8810-4e10-869b-c3d1f0464128

Label:          (no label)

Subsystem:      (no subsystem)

Flags:          (no flags)

Data segments:

  0: crypt

        offset: 16777216 [bytes]

        length: (whole device)

        cipher: aes-xts-plain64

        sector: 512 [bytes]

Keyslots:

  0: luks2

        Key:        512 bits

        Priority:   normal

        Cipher:     aes-xts-plain64

        Cipher key: 512 bits

        PBKDF:      argon2i

        Time cost:  4

        Memory:     1027952

        Threads:    4

        Salt:       a6 c1 91 78 d7 e1 bd 64 13 05 1c 4f 86 1c 03 e9

                    ba b4 a0 a4 3f 65 33 33 33 33 33 33 33 58 06

        AF stripes: 4000

        AF hash:    sha256

        Area offset:32768 [bytes]

        Area length:258048 [bytes]

        Digest ID:  0

  1: luks2

        Key:        512 bits

        Priority:   normal

        Cipher:     aes-xts-plain64

        Cipher key: 512 bits

        PBKDF:      argon2i

        Time cost:  4

        Memory:     1010545

        Threads:    4

        Salt:       04 94 07 b6 80 19 18 f7 df ca a9 6d 82 d3 b0 3b

                    2d 4b 29 33 b7 07 d3 33 33 33 33 64 1d 91 fd

        AF stripes: 4000

        AF hash:    sha256

        Area offset:290816 [bytes]

        Area length:258048 [bytes]

        Digest ID:  0

  2: luks2

        Key:        512 bits

        Priority:   normal

        Cipher:     aes-xts-plain64

        Cipher key: 512 bits

        PBKDF:      argon2i

        Time cost:  4

        Memory:     1014851

        Threads:    4

        Salt:       93 63 36 66 66 66 66 66 8c 7a c3 53 28 da 69

                    f4 3c 4f 95 ce 1e c5 58 2c 77 57 9e 42 84 f7 e8

        AF stripes: 4000

        AF hash:    sha256

        Area offset:548864 [bytes]

        Area length:258048 [bytes]

        Digest ID:  0

  3: luks2

        Key:        512 bits

        Priority:   normal

        Cipher:     aes-xts-plain64

        Cipher key: 512 bits

        PBKDF:      argon2i

        Time cost:  4

        Memory:     1019473

        Threads:    4

        Salt:       cd ca 7e 40 0c 34 72 93 ac 8b 91 ef 71 38 23 1c

                    34 a5 f3 66 31 33 33 33 33 33 33a2 58 88 71

        AF stripes: 4000

        AF hash:    sha256

        Area offset:806912 [bytes]

        Area length:258048 [bytes]

        Digest ID:  0

  4: luks2

        Key:        512 bits

        Priority:   normal

        Cipher:     aes-xts-plain64

        Cipher key: 512 bits

        PBKDF:      argon2i

        Time cost:  4

        Memory:     1023535

        Threads:    4

        Salt:       9e c6 69 4d 1c 37 bf 0d 02 a8 00 a3 fe a1 ee 1e

                    59 8f d2 5d d9 33 33 33 33 33ae 87 d9 a1 53 c6

        AF stripes: 4000

        AF hash:    sha256

        Area offset:1064960 [bytes]

        Area length:258048 [bytes]

        Digest ID:  0

  5: luks2

        Key:        512 bits

        Priority:   normal

        Cipher:     aes-xts-plain64

        Cipher key: 512 bits

        PBKDF:      argon2i

        Time cost:  4

        Memory:     1011001

        Threads:    4

        Salt:       1b aa f1 e3 8a 0c c6 ef eb 1d 99 81 75 fd b1 b6

                    f2 45 7e 8d 4c 66 66 66 66 80 03 13 53 a8 4a

        AF stripes: 4000

        AF hash:    sha256

        Area offset:1323008 [bytes]

        Area length:258048 [bytes]

        Digest ID:  0

Tokens:

Digests:

  0: pbkdf2

        Hash:       sha256

        Iterations: 64125

        Salt:       23 f5 34 05 e6 bc a5 f4 87 44 44 44d8 92 74 fc

                    62 40 8a 32 60 88 31 ac 87 48 1f 6a 98 97 09 eb

        Digest:     c7 4c a4 44 44 44 44 d0 de 68 67 97 56 d8 1b

                    a8 b3 b7 7a 4a 87 bb 0e c0 c4 d1 f2 96 23 0f 86
```

Last edited by finalturismo on Tue Oct 06, 2020 5:59 pm; edited 3 times in total

----------

## pietinger

 *finalturismo wrote:*   

> The problem i am having is that, dmcrypt is not auto unlocking the drive on boot with the key specified in /etc/keyfiles/main.key.

 

Do you get an error from dmcrypt ?

Do you try to unlock a root partition with /etc/init.d/dmcrypt and a keyfile ? (if yes, the keyfile must reachable for the kernel before)

I dont know if it is important to put your settings in apostrophes. I do it and it works:

```
 ## /home with regular keyfile on removable media(such as usb-stick)

target=crypt-home

source='PARTLABEL=home'

key='/mkey'

remdev='PARTLABEL=crypto'

options='-c aes-xts-plain64 -s 512 --allow-discards'
```

And you will see it also in /etc/conf.d/dmcrypt:

```
[...]# source='<dev>'                     == Real device for partition.

#                                    Note: You can (and should) specify a tag like UUID

#                                    for blkid (see -t option).  This is safer than using

#                                    the full path to the device.

# key='</path/to/keyfile>[:<mode>]'  == Fullpath from / or from inside removable media.

# remdev='<dev>'                     == Device that will be assigned to removable media.

# gpg_options='<opts>'               == Default are --quiet --decrypt

# options='<opts>'                   == cryptsetup, for LUKS you can only use --readonly

# loop_file='<file>'                 == Loopback file.

#                                    Note: If you omit $source, then a free loopback will

#                                    be looked up automatically.

# pre_mount='cmds'                   == commands to execute before mounting partition.

# post_mount='cmds'                  == commands to execute after mounting partition.

#-----------

# Supported Modes

# gpg                                   == decrypt and pipe key into cryptsetup.

#                                               Note: new-line character must not be part of key.

#                                               Command to erase \n char: 'cat key | tr -d '\n' > cleanKey'

#--------------------

# dm-crypt examples

#--------------------

## swap

# Swap partitions. These should come first so that no keys make their

# way into unencrypted swap.

# If no options are given, they will default to: -c aes -h sha1 -d /dev/urandom

# If no makefs is given then mkswap will be assumed

#swap=crypt-swap

#source='/dev/hda2'

## /home with passphrase

#target=crypt-home

#source='/dev/hda5'

## /home with regular keyfile

#target=crypt-home

#source='/dev/hda5'

#key='/full/path/to/homekey'

[...]
```

(at the moment my notebook is away and I cant test it)

----------

## finalturismo

 *pietinger wrote:*   

> 
> 
> Do you try to unlock a root partition with /etc/init.d/dmcrypt and a keyfile ? (if yes, the keyfile must reachable for the kernel before)
> 
> 

 

How do i do this?

 *pietinger wrote:*   

> 
> 
> Do you get an error from dmcrypt ?
> 
> 

 

Where do i check the log?

 *pietinger wrote:*   

> 
> 
> I dont know if it is important to put your settings in apostrophes. I do it and it works:
> 
> 

 

I already tried that -.-

Its at times like this i wish Linux Tarvolds was my best friend. Wonder if i drank his blood what will happen.

----------

## pietinger

 *finalturismo wrote:*   

> How do i do this?

 

The keyfile must reside on an unencrypted partition, like an USB-stick or another (unlocked) partition:

The most used action when using /etc/init.d/dmcrypt and a keyfile is:

a) encrypting the root partition with initramfs/luks and then encrypting /home and /swap (and others) with dmcrypt using a keyfile from /root, OR

b) encrypting /home and /swap (and others) with dmcrypt using a keyfile from an USB-stick. (*)

Another way is using initramfs/luks AND lvm and no /etc/init.d/dmcrypt.

(* there is another unusual way I described here: https://forums.gentoo.org/viewtopic-t-1110764-highlight-.html)

----------

## finalturismo

 *pietinger wrote:*   

>  *finalturismo wrote:*   How do i do this? 
> 
> The keyfile must reside on an unencrypted partition, like an USB-stick or another (unlocked) partition:
> 
> The most used action when using /etc/init.d/dmcrypt and a keyfile is:
> ...

 

Ya so unlock the drive with a keyfile on an external device seems easy enough but i already have a feeling that will work fine. 

I think you just hit the nail on the head, i just removed my kernel parameters and put back the / location in fstab. 

I think the initramfs luks addon was overriding the dmcrypt procedure. Kernel compiling now... Think this will solve issue...

If iam not running an lvm encryption setup , that means i dont need any kernel parameters  just my dmcrypt mounting file and make sure dmcrypt is running at boot correct?

----------

## finalturismo

bump, still no dice

Iam getting an initramfs message saying 

```
/dev/mapper/root cannot be mounted
```

.....

This is strange because i rebuilt the initramfs after editing my kernel parameters so iam not sure how it is getting that name? from the UUID maybe?

I was reading the custom initramfs section and i came across this

https://wiki.gentoo.org/wiki/Custom_Initramfs#Encrypted_keyfile

 *Quote:*   

> If your root partition is LUKS encrypted, you need to include the cryptsetup binary in your initramfs. You can get a static binary by setting the static USE flag for sys-fs/cryptsetup. Copy it to your initramfs /sbin directory. Since cryptsetup also often requires the use of the kernel's random device, include them as well.

 

Does this still apply or is it old? i did not see this in the "Full Disk Encryption From Scratch Simplified" guide

Just need the key to be applied during boot......

Not so good at debugging and i dont want to be trying a million ways till it works XD. i need to know whats exactly going on somehow.

----------

## Hu

I would start by adding generous logging.  Get to the point that every message you get can be traced to a specific program call that was made.

You may find it useful to test some of this in a virtual machine.  You can iterate very quickly that way, especially if you use one, such as Qemu, which lets you supply the kernel externally, so you do not need to successfully boot the guest in order to update to a newer test kernel.

As regards cryptsetup, you can use a dynamic cryptsetup.  That has always been true.  It is arguably more work to set up, since it becomes your responsibility to provide the supporting libraries.  Using a static cryptsetup avoids that, at the expense of needing to build a static cryptsetup first.

I don't see your initramfs's init script in this thread, so we cannot review it for mistakes.  Please post or pastebin the script, and a list of what files are in the initramfs.

----------

## finalturismo

 *Hu wrote:*   

> I would start by adding generous logging.  Get to the point that every message you get can be traced to a specific program call that was made.
> 
> You may find it useful to test some of this in a virtual machine.  You can iterate very quickly that way, especially if you use one, such as Qemu, which lets you supply the kernel externally, so you do not need to successfully boot the guest in order to update to a newer test kernel.
> 
> As regards cryptsetup, you can use a dynamic cryptsetup.  That has always been true.  It is arguably more work to set up, since it becomes your responsibility to provide the supporting libraries.  Using a static cryptsetup avoids that, at the expense of needing to build a static cryptsetup first.
> ...

 

So turns out i was just being an idiot and trying to use the key on the encrypted drive to decrypt the drive XD... silly me....

Iam about to take launch really quick. 

It is possible to build the key file into the initramfs correct? i need that key file to be protected too. I just need the system to decrypt at every boot so the end user can use it, but so it is protected against corporate theft. This thing is going to a few bigger companies and iam a bit nervous.... i cant have it get stolen. 

anyway building the cryptsetup into the initramfs looks fairly simple... When all is said and done how can i make sure the initramfs is protected too?

I  might be going too deep into this when there is a simpler way of decrypting the drive at boot while protecting the key. Like is there a crypt setup command that installs the key into initramfs and protects initramfs? 

The key needs to somehow be in a binary that way it cannot be extracted with a docking station and used to decrypt the drive. It would be totally safe in a binary file...

Anyway off to get some food iam going to be looking at this thread 24/7 waiting for replys XD. You guys are my only hope.

----------

## Hu

You can bundle the key into the initramfs.  Your problem is that you can either make the initramfs able to boot unattended, in which case anyone who steals it can extract everything they need to read the disk without using your code; or you can make the initramfs need human intervention to boot, in which case the thief will need that same human intervention.  There's no way to have:Boots unattendedOnly boots exactly what you approveNo external dependenciesYou might be able to get everything you want if you can hide the key in a TPM.  That adds complexity elsewhere, and is something that you will find far less expertise to guide you.

----------

## finalturismo

 *Hu wrote:*   

> You can bundle the key into the initramfs.  Your problem is that you can either make the initramfs able to boot unattended, in which case anyone who steals it can extract everything they need to read the disk without using your code; or you can make the initramfs need human intervention to boot, in which case the thief will need that same human intervention.  There's no way to have:Boots unattendedOnly boots exactly what you approveNo external dependenciesYou might be able to get everything you want if you can hide the key in a TPM.  That adds complexity elsewhere, and is something that you will find far less expertise to guide you.

 

OMG the TPM part sounds like it might be pretty easy... thats a great point. So i would just need to mount the TPM at start and place the key inside of the tpm. Iam guessing the process goes something like this. 

The only problem with that is it would require configuration per unit we deploy. 

Now as far as the initramfs iam almost finished with it, i was just putting the grub stuff in so it is recognized by mk-config. But you make it so sound like like it may not be possible for initramfs to be protected?

You cant compile the filesystem into like a binary?

I mean what iam wanting to do is very simple it just requires you to somehow build a protected initramfs or binary with the key inside. What about the kernel? is there anyway to build the key into the kernel so the OS is unlocked at start?

If i was a master coder i would just do this my self but iam not so i have to dig and dig.

I somehow need to get this keyfile protected too while it is being used to boot the system. 

This system is supposed to be stupid proof, so having the end user type a password at start cant be a solution for me. 

Also with that password they could decrypt the drive with knowledge of cryptsetup. 

The goal is to create a bootable system where the drive cannot be read when removed from the system. (Purpose of encryption here)

The system boots with a web gui and the system cannot have root access unless you SSH / chmod into it.  

Both of those requiring a password which they wont have. You see what iam trying to do right?

protect the system so no one can  see the code or Linux inner workings unless they have root access.

----------

## Hu

I see your goal, and I maintain that it is not a good use of your time.  Yes, a TPM would likely require per-system setup.  Yes, you can put the key into the initramfs.  A skilled user could extract that initramfs, extract the key from it, and use it to boot the system without running your code.  Depending on other aspects of how you put this together, that might not even be the easiest way to get into the system.

Why do you think the person authorized to power this system on cannot be given access to the root filesystem?  I understand if you want to avoid support calls after the user breaks something.  For that, just make it difficult for them to get the key from the initramfs.  If you want to guarantee that none of the experts here can get into the system in reasonable time, that's a much higher bar, and needs a good justification for the work.

----------

## 389292

Ho I do my encryption:

part1 unecrypted grub bootloader

part2 encrypted /boot (boot, grub, the kernel, the keyfile, and the initramfs image are here)

part3 encrypted /home

procedure: during boot the bootloader tries to decrypt /boot, sees encryption and asks for password, after getting it it decrypts part2 and runs initramfs from it, it then decrypts the rest of the drives with the keyfile following the initramfs init script.

I did not use genkernel in making of initramfs, because I found it unreliable, you are passing some options but what happens underneath you have no idea, it may not copy the needed binaries and your initramfs will not be usable, better to do it manually, after writing a script it takes 2 seconds to create initramfs, and you will know exactly what it uses and the boot sequence.

 *Quote:*   

> so having the end user type a password at start cant be a solution for me. 

 

I don't think this is possible then, how would you protect something without a password, I mean even theoretically....

---

Maybe try digging into 'kiosk' type machine setup, extreamlly locked, nothing is allowed, with tons of iptables, user groups, apparmor/selinux rules. But it's not going to be easy, this is an advanced stuff even for seasoned linux user.

----------

## finalturismo

 *Hu wrote:*   

> I see your goal, and I maintain that it is not a good use of your time.  Yes, a TPM would likely require per-system setup.  Yes, you can put the key into the initramfs.  A skilled user could extract that initramfs, extract the key from it, and use it to boot the system without running your code.  Depending on other aspects of how you put this together, that might not even be the easiest way to get into the system.
> 
> Why do you think the person authorized to power this system on cannot be given access to the root filesystem?  I understand if you want to avoid support calls after the user breaks something.  For that, just make it difficult for them to get the key from the initramfs.  If you want to guarantee that none of the experts here can get into the system in reasonable time, that's a much higher bar, and needs a good justification for the work.

 

Well you and my boss got me on 1 thing, not a good use of my time. But me and a friend have been developing some drive wiping software for the course of over a year. Lets just say it puts killdisk to shame.

It has a Google style GUI and can wipe 100S  of hard drives at once without failure or freezes. It uses a SAS 9300-8e IT mode card for the SAS controller(IT mode cards handle failed drives without causing chaos).  All the drives that are wiped have certificates generated for them automatically and logs are generated based on all the drives wiped. The wiper converts net app drives from 520 to 512 sector automatically for use in standard system or for resale.  You can take a SAS cable and plug it into an entire data-center storage rack and it will wipe the drives with zero issues. It uses image magik to print data to a picture and everything is driven by a web gui and node.js for speed. It is supposed to be retirement for me and my friend. You can also batch the drives into company sections that are auto colorized based on the company. We have 3 beta tester clients that all agree its the best thing they ever used.  You can upload new certificates , company logos and start a PXE server to take down an entire network and document it.  It uses Hdsentinel, SG_utilis , Mysql, nginx, node.js,php, supervisor, and Gentoo Linux (for stability and lack of systemd, we choose it to be our OS for the base.) Certificates can be backed up and reloaded. Right now we have the software doing an auto ssh tunnel back to the home server for manual updates and testing. I have been in the recycling business and using software like killdisk for the past 6+ years and based some data security requirements and documentation we built a drive software around wiping mass drives that can present the data to clients. It should take off in major companies and have good use in the government sector.  We did not expect it to come out as good as it did, my friend is also a software enginner and has helped me with most of the really hard back end coding..... It came out better than we could of expected. We are extremely nervous about anyone coping the drive or looking into the software. Right now we only have the php and node.js files protected but because more people are wanting to test the software and use it in house we need to make sure it gets locked down. We have even gone as far as modding the kernel to prevent any partition scanning of the drives inserted, to further increase stability. (no more access to partitions like sda1,sda2... etc.....)

I hope thats reason enough for ya  :Smile:  i could include some pictures later if you like. I have been on this forum more than once for help with it. We got some help doing the initramfs part and it uses broadcast messages over Ethernet for some of the commands when running on client computers.

Anyway i was reading that a kernel key ring can also be used for the encryption. Iam not sure on the process. 

But since you mentioned using TPM that can be our last ditch effort and i dont think it will be too hard for me to setup.   I want this done right with no unexpected events... there has been an incredible amount of man hours put into this and i don't want it to be for nothing. Also peoples response on software has been amazing. If you saw iam sure you would be VERY impressed. It will literally be hands down the best disk wiping software on the internet, hands down and no questions asked.  I was actually looking for another backup coder too because my friend sometimes gets extremely busy and he knows the node.js and php stuff that i couldnt do. Hes the best of the best. I felt the need to share some of my personal reasoning's behind this because i have learned alot just from being on this forum and i greatly appreciate all the knowledge you guys share.

 *etnull wrote:*   

> Ho I do my encryption:
> 
> part1 unecrypted grub bootloader
> 
> part2 encrypted /boot (boot, grub, the kernel, the keyfile, and the initramfs image are here)
> ...

 

We do use a kiosk type mode, it boots using inittab and a cacheless chrome browser in kiosk mode. You cant get into any terminals unless you ssh to it from another machine.  All blocked via init-tab. Some other clients want to start testing and my boss is pushing me to deploy more units for testing but iam starting to get nervous now and i want it locked down.  So now yall know why i have been coming here for help with random things, this is the majority of the reason and its a good one.Last edited by finalturismo on Wed Oct 07, 2020 7:16 am; edited 1 time in total

----------

## Hu

At some point, it is time to involve lawyers.  Based on your description, I see two reasons to bring in a lawyer at this point.  First, you can't fully secure this against copying through purely technical means.  You could secure it well enough that most people can't copy it, but if this is good enough to draw the attention of the right kind of person, you only need one expert to have it break down.  If you are concerned about someone copying your work and profiting from it, put it behind a license agreement that forbids such actions.  A lawyer can help you draft one that will be enforceable and do what you want.  You could write one yourself, but for the amount of work you have put into this product so far, and your expectations of what you will gain from it, I would want a professional review to ensure there are no gaps in the license.

Second, based on your list of components you used, you're almost certainly using at least some software that has license terms you need to be aware of, and in compliance with, before you draw unwanted attention to yourself.  For example, for the GPL-licensed components you used, have you extended to every customer the appropriate notifications and offer of source code?  Have you kept enough internal records that you could correctly satisfy a request if someone exercised their right to a copy of that GPL'd code?  A lawyer specialized in software licensing may be appropriate to make sure you do not do something that will come back to trouble you later.  This seems especially pertinent here, since your interest in locking down your portion of the work will incidentally lock down the freely licensed portions, and some rightsholders may be more likely to raise a stink over a locked down non-compliant device than over a freely modifiable non-compliant device.

----------

## finalturismo

 *Hu wrote:*   

> At some point, it is time to involve lawyers.  Based on your description, I see two reasons to bring in a lawyer at this point.  First, you can't fully secure this against copying through purely technical means.  You could secure it well enough that most people can't copy it, but if this is good enough to draw the attention of the right kind of person, you only need one expert to have it break down.  If you are concerned about someone copying your work and profiting from it, put it behind a license agreement that forbids such actions.  A lawyer can help you draft one that will be enforceable and do what you want.  You could write one yourself, but for the amount of work you have put into this product so far, and your expectations of what you will gain from it, I would want a professional review to ensure there are no gaps in the license.
> 
> Second, based on your list of components you used, you're almost certainly using at least some software that has license terms you need to be aware of, and in compliance with, before you draw unwanted attention to yourself.  For example, for the GPL-licensed components you used, have you extended to every customer the appropriate notifications and offer of source code?  Have you kept enough internal records that you could correctly satisfy a request if someone exercised their right to a copy of that GPL'd code?  A lawyer specialized in software licensing may be appropriate to make sure you do not do something that will come back to trouble you later.  This seems especially pertinent here, since your interest in locking down your portion of the work will incidentally lock down the freely licensed portions, and some rightsholders may be more likely to raise a stink over a locked down non-compliant device than over a freely modifiable non-compliant device.

 

Ya my boss is supposed to be taking care of that part soon. I did get permission from HD sentinel to use their software for the health monitoring portion of it. I looked up the GPL and did some reading, from what i understand i have the right to use it in software i sell but i cannot sell their software directly or make modifications to it without permission. But than again i am not a lawyer. The only software that had some licensing issues i knew of was HD Sentinel and i got their permission, but than again i could be missing something. 

Regarding the TPM i only need to utilize the feature of unlocking it VIA the password set in the bios. Than drop the keyfile into /dev/tpm.  From what i have been reading seems  very easy...

i would have to include the /etc/dmcrypt.conf in the initramfs so it can talk to the dmcrypt file outside of the encrypted drive? or when i create the initramfs  with "genkernel initramfs --luks" it does this for me?

This seems to be the only part i dont get. I know i could make a custom initramfs but do i ever need to do that if iam dropping the key inside of the TPM?

The TPM sounds the best route actually, because we are going to be selling the hardware with the software as 1 unit.

----------

## Hu

 *finalturismo wrote:*   

> I looked up the GPL and did some reading, from what i understand i have the right to use it in software i sell but i cannot sell their software directly or make modifications to it without permission.

 That is not how I understand the GPL.  You can sell software that is licensed under the GPL, but you cannot prevent recipients from gifting away or reselling the GPL-covered software.  Thus, selling GPL-covered software is very unlikely to be profitable, since if the software is desirable, some recipient may exercise their right to gift or resell it, cutting into the original vendor's profits.  (There is a special case here: some companies have done well selling physical media that contains GPL-covered software, because their customers are really paying for the convenience of getting the software on physical media, saving the customer the inconvenience of downloading the software (sometimes from many independent locations) and creating their own physical media.  This was more common when distributing software on floppy disks or compact discs was still a routine event.  Other companies sell you a support contract that happens to come with GPL-covered software.  They make their money betting that providing the contracted support will, on average, cost them less than what you paid for the support contract.)

You do not need advance permission to modify the software.  However, if your only rights to the software come through the GPL, then you do need to comply with its limitations, particularly those around notifying recipients of the existence of the GPL-covered work and of their rights that result from the GPL.  Also, you must be ready to fulfill your obligations if someone exercises their right to a copy of the source.  The GPL outlines all of this in more detail.  Whoever is assigned to handle license compliance should read the license in detail, and may need specific actions from you or some other technical contributor afterward.  For example, you will likely want to save a copy of the build environment so that you can completely rebuild any past release.  If you can do that, then supplying complete corresponding source is much easier. *finalturismo wrote:*   

> i would have to include the /etc/dmcrypt.conf in the initramfs so it can talk to the dmcrypt file outside of the encrypted drive? or when i create the initramfs  with "genkernel initramfs --luks" it does this for me?

 I have never tried to do what you want.  My initramfs' are not designed for unattended boot, so they just run cryptsetup open --type luks $path_to_device $dmname, and wait for the user to enter a password. *finalturismo wrote:*   

> This seems to be the only part i dont get. I know i could make a custom initramfs but do i ever need to do that if iam dropping the key inside of the TPM?

 That depends on whether you can get the initramfs to retrieve the key from the TPM at boot.  I don't know if you can do that without a custom initramfs.  I have never tried.

----------

## pietinger

finalturismo,

you are right, you need TPM and therefore you need secureboot (without you cant use TPM) ... and ... you need this link   :Wink: 

https://threat.tevora.com/secure-boot-tpm-2/

----------

## salahx

Actually, you do not need secureboot to use the TPM. One thing to watch out for some of the tpm2-tools tool and parameters names have changed.

So, using the document you were given, the actual commands should be:

```

dd if=/dev/urandom of=secret.bin bs=32 count=1

tpm2_pcrread sha1:0,2,3,7 -o pcrs.bin

tpm2_createpolicy --policy-pcr -l sha1:0,2,3,7  -f pcrs.bin -L policy.digest

tpm2_createprimary -C o -c SRK.ctx

tpm2_create -u obj.pub -r obj.priv -C SRK.ctx -L policy.digest  -a "noda|adminwithpolicy|fixedparent|fixedtpm" -i secret.bin

tpm2_load -C SRK.ctx -u obj.pub -r obj.priv -c load.ctx

tpm2_evictcontrol -c load.ctx 0x81000000

```

One thing to be careful of is in TPM2 policies are immutable - you cannot change the policy of an object once its created. So if the any of PCR change, you will  not be able to recover the content or re-lock it to different PCR. However, TPM2 also provides for a "wildcard" policy that allow you to defines a key to sign a policy, then you can authorize any policy signed with that key. 

You can do that like this:

```

openssl genrsa -out policy.priv 2048

openssl -in policy.priv -pubout policy.pub

tpm2_loadexternal --C o G rsa -c policykey.ctx -u policy.pub -n policykey.name

tpm2_startauthsession -S session.ctx

tpm2_policyauthorize -S session.ctx -n policykey.name -L policykey.digest

tpm2_flushcontext session.ctx

tpm2_create -u obj.pub -r obj.priv -C SRK.ctx -L policykey.digest  -a "noda|adminwithpolicy|fixedparent|fixedtpm" -i secret.bin

tpm2_load -C SRK.ctx -c load.ctx  -u obj.pub -r obj.priv

tpm2_policypcr -S session.ctx -l sha1:0,2,3,7  -f pcrs.bin -L policy.digest

tpm2_flushcontext session.ctx

openssl dgst -sha256 -sign policy.priv -out policy.sig policy.digest

tpm2_verifysignature -c policykey.ctx -f rsassa -g sha256 -m policy.digest -s policy.sig -t policy.tkt

tpm2_startauthsession -S session.ctx --policy-session

tpm2_policypcr -S session.ctx -l sha1:0,2,3,7  -f pcrs.bin 

tpm2_policyauthorize -S session.ctx -n policykey.name -i policy.digest -t policy.tkt

tpm2_unseal -c load.ctx -p session:session.ctx -o secret.new

tpm2_flushcontext session.ctx

diff secret.bin secret.new

```

It takes a while to understand this. I hightly recommend installing app-crypt/swtpm, creating a VM with a TPM 2.0 for experimentation.

----------

## finalturismo

 *salahx wrote:*   

> Actually, you do not need secureboot to use the TPM. One thing to watch out for some of the tpm2-tools tool and parameters names have changed.
> 
> So, using the document you were given, the actual commands should be:
> 
> ```
> ...

 

Thanks for your help and understanding guys, i really got more than i asked for here. 

By any chance does anyone here skills in Node.js and Php? iam looking for another Dev, someone trustworthy and friendly mainly.

----------

