Wilkinson module devoted to encryption and mechanisms implemented directly by windows that allow data
encryption restart from the operating system protects the confidentiality of critical data.
For example various types of credentials.
Above all we have to clipboards boards for data data protection API is a Windows subsystem responsible
for security.
It protects both user data each user in a separate storage and the computer itself.
Let's see how it looks for keys secure communication using SSL protocol or secure communications using
a secure version of Internet Protocol or IPS require secure key storage keys are stored locally on the
system drive.
They're not however stored in plaintexts but encrypted to encrypt something you need to have the key
that encrypts it and later decrypt it.
In this case it's the Data Protection API DP API key on the same level as the DPA API.
There's this security account manager database the SAM file.
If we're talking about a local computer or the Active Directory database if we're talking about domain
controllers as well as Zella say local security authorities subsystem security secrets Elisei secrets
include account passwords use to start system services.
If the computer is a domain controller when it promotes this role we need to give the password of the
local administrative account and domain controllers.
There are no de-facto local accounts.
It's difficult to imagine running a domain controller while not running the domain at the same time
if different errors or inconsistencies appear in the Active Directory database.
The safe mode must be available in the safe mode.
We log onto the account with the appropriate password.
Secrets of that level are then encrypted with the start key whose location we can configure using Assissi
program by default.
It's stored in the registry on a hard disk drive where Windows is installed.
We can also transfer it to a floppy disk.
Then this disk would need to be connected to the system during startup.
It can also be derived from the password that Windows asks for during logging.
In regards to the user the situation is very similar.
The user may have for example keys.
We'll talk about them in this module.
In other words encrypting file system keys a user may also have kids that allow a safe exchange of data
by email.
In other words as mime protocol keys these kids are stored locally.
By default they're protected by DPA API keys on the user account not on the computer or account on the
same level.
There's a user's profile data.
This level is also protected with a start key.
The result is such that if we have the startup key we have access to data from the sound file level.
If however we have the DPA API key we automatically have access to the SSL and IPS keys everything is
encrypted but the user does not need to provide any decryption keys.
The default configuration is fully automatic though the configuration is automatic.
It does not mean that it is absolutely safe.
The purpose of the encryption is to guarantee the confidentiality of data.
Someone who is not familiar with encrypted messages may haphazardly change it.
The ciphertext can always be changed.
In the simplest case you can delete it.
We've seen the programs work in this way to allow resetting the local administrator password if we wanted
to encrypt all the data or we've talked about earlier.
Plus everything on the computer disk we would need to encrypt the entire disk.
At this point several problems appear one of the immutable principles of computer security states that
the ciphertext is only as safe as the key used to decrypt it.
Once we encrypt the entire disk where will we write the key to decrypt it.
This is the first problem.
The strength of the ciphertext depends on the way in which we encrypt the data.
As end users we don't have much impact on this.
However we can always consciously choose the algorithm the strength of the ciphertext depends on the
length of the key.
This is not a proportional relationship.
Generally however a longer key improves the safety of the ciphertext.
It's not that key which is two times longer will give us two times higher security but we will be a
little safer.
Disk encryption uses symmetric algorithms that do not allow data encryption of any links.
They only allow encrypted data blocks with a strictly defined length.
If we use the same algorithm to encrypt many successive blocks it turns out that the ciphertext is very
easy to break even if the queue was long and the algorithm secure.
Here we're talking about cryptographic systems and in particular block cipher modes when selecting the
method of encrypting the disk when needed not only to deliberately choose the algorithm in length but
also the block cipher mode.
If we have such in the case of bit locker and true crypt this can be selected if we encrypt disks we
need to use solutions that when saving automatically encrypt each sector meaning 512 bytes of disk space.
The solution also needs to automatically decrypt sectors while reading.
It would also be good that during the entire encryption and decryption computer performance would not
visibly be reduced when designing bit Locker which was quite a few years ago it was assumed that when
reading a single byte the processor can execute from 50 to 100 individual instructions or cycles.
Therefore the assumption was adopted that the encryption of one byte data units cannot burden the processor
with more than 35 cycles.
But Lucker uses the ABS algorithm to encrypt a single chunk of which requires about 20 processor cycles
This means that it's in the range.
Even for computers produced five years ago.
Since we're deciding on data encryption we should be certain not only as to its confidentiality but
also its authenticity ensuring the authenticity of encrypted data on the entire disk is relatively difficult.
Most often the method used is attaching a signature to the ciphertext at the same time.
This indicates whether someone has changed the ciphertext or not.
In the case of encrypting the entire disk This is not an option because where will the signature be
saved.
Some intermediate solution needs to be adopted a haphazard change to the ciphertext needs to be more
difficult.
How can this be done.
Diffusion can be applied in other words a diffuser.
It works so that a change of one byte in the sector will cause a pseudo random change of a large number
of bytes in other sectors.
The effect will be as such that if someone suspects that at a certain place in the ciphertext there
is a SAM file and tries to reset the administrator password by deleting the corresponding ciphertext
bytes than the contents of many files of the operating system will automatically be changed.
The result will be that the system will not boot at all.
That's why in addition to the ABS algorithm and bit locker and original algorithm by Microsoft Research
is used which is called defuser.
It requires about 10 cycles for use in one byte.
The result is such that for today's computers the activation of the almost invisible protection of the
entire hard disk drive is connected with the reduction of efficiency of about 5 percent.
That's all concerning the basis of cryptography and data security encrypted disks must be managed in
some way especially in companies.
We need to have the possibility of remote administration and remote program configuration that will
encrypt and decrypt data.
After all we will not do it to each computer separately.
In addition some embedded emergency mode is mandatory.
What do you do in a situation when a user we encrypted data for or the user encrypted the entire disk
himself forgets a password.
For example the password that allows him to decrypt the disk there must be some way to decrypt data
on the disk on behalf of the user.
Of course this affects security because it's based on trust to the administrator.
Additional benefits of programs that encrypt the disks could be something like hiding the fact of the
presence of data on the disk.
This is something that has not been implemented in bit locker.
This is something that makes true Krips stand out as compared to a bit locker.
Sure Krips has such functionality that when one disk is encrypted it will create a second disk encrypted
with a different key.
Since both these disks are encrypted the analysis of these disk content for example when the computer's
off does not show any difference between one encrypted disk and the other.
In general it should be maximum pseudo random data.
Now if someone asks us to decrypt a disk in most cases those who authorize to do so such as the police
if they ask us we have the obligation to reveal to them the password for this type of security.
If we have the password to one disk it will be decrypted and its content made available.
If however we don't give a second password everything that was encrypted and was on the internal hard
disk will remain invisible at least in theory an additional advantage to disk encryption could also
be checking the integrity of the computer.
This function is only available in bit locker and is not available in true crypt.
It's idea is that interference in the computer for example moving the hard disk or a change in the order
of the starting devices causes automatic blocking of the encrypted disk.
We've already mentioned authenticity.
Said that a signature is used for it.
However in the case of disks that's not possible since the sector has a fixed sector size.
We can't force manufacturers of hard disks and low level software to reserve for us a few extra bytes
in each sector.
We also can't write checksums to another sector since there are programs that are based on the fact
that sectors are independent of each other.
Examples of such programs are database servers which in their own way manage writing and reading.
It cannot be that a change in data in one sector causes their automatic change in another sector.
This is what would happen if a check somewhere there we could solve the problem by artificially doubling
the size of the sector.
Then all the problems are solved.
We have a lot of space for the checksum.
In addition the operating system is only half of the sectors and there are no relationship between the
sectors.
Unfortunately we'd have to convince users that when buying for example a 500 gigabyte disk it really
has to be 250 gigabytes.
We could meet some resistance there for disk encryption software.
Instead of using Macs signature's broadcast bits on as many sectors as possible in addition to encryption
specific sectors use keys to avoid simple mathematic relationship.
Well then.