Learn WIP with Joy – File Protection Deep Dive – Part 3

6
Windows Information Protection - $EFS attribute stores protection information

Hello! Hope you are all doing good and are safe along with your friends and family.

This is the last and concluding artcile on Windows Information Protection series that I started “Learn WIP with Joy!” If you have not read Part 1 and Part2 of the series yet, I would urge you to read those in sequence 1st before continuing with this.

Today in this article, I will be taking you through the following topics

  • general flow of EFS file protection
  • any deviations when EFS is invoked by WIP
  • importance of DRA in WIP policy
  • WIP file protection when file copied to removable media
  • discuss the limitations of WIP

Let’s get started.

[Recap] EFS – The components involved

I will continue from where I left off in Part 2 of this article series – EFS the worker behind WIP file protection. Below is an overtly simplistic overview of the components that are responsible for the EFS functionalities.

Windows Information Protection - An overview of the EFS components which handles the file encryption
Windows Information Protection – An overview of the EFS components which handles the file encryption

The main components of EFS are

Kernel Mode

  • NTFS File System
  • EFS Driver

User Mode

  • EFS service [runs within the LSASS process] (LSASS handles crypto key requests utilizing EFS functions)
  • CryptoAPI
Windows information Protection - User mode EFS service runs within the LSASS process
User mode EFS service runs within the LSASS process

As mentioned, this is a very high level view of the components involved. Explaining the entire flow in details is not a scope of this article. You can find good documentations on EFS over the internet, like this.

Rather than the components involved, our focus is on the working mechanism of EFS encryption. Let’s start with uncovering the process flow for EFS file encryption in general.

EFS encryption process in a nutshell [Generalized]

If you have read Part 2, you would know that EFS file encryption uses both symmetric and asymmetric keys. The symmetric key (FEK) is used for encryption/decryption of the file content where as a RSA public/private key pair generated for the user account is used to protect the FEK so as to ensure protection and restrict unauthorized file access.

A simplistic overview of the EFS encryption process is as shown below

Windows Information Protection - schematic flow of the EFS encryption mechanism
Schematic flow of the EFS encryption mechanism
Altaro Office 365 Backup
Advertisement Altaro Office 365 Backup

Preliminary Requirement – Check for a public/private key pair

On a Windows 10 endpoint, when you manually encrypt a file, either by

  • using File Explorer, marking the checkbox for Encryption from the Advanced menu of file Properties
Windows Information Protection - Manually encrypting file using EFS
Manually encrypting file using EFS
  • using the cipher cmdline tool command: cipher /e <filename(complete path to file if not in present location)>

EFS checks to see

  • if the current signed-in user account has a public/private key pair which can be used for EFS encryption. Basically a check in the user’s Personal certificate store to see if it has any cert with EKU for EFS.
  • if no such key pair is found, EFS generates a public/private key pair (RSA 2048 bit) for the current signed-in user account.

This results a self-signed certificate (EKU is EFS) for the public/private key pair. The public key cert is added to User Personal Certificate store as shown below. (%AppData%\Microsoft\SystemCertificates\My\Certificates)

Windows Information Protection - EFS generated self-signed cert for the public key of the public-private key pair generated for the user account used for protecting the FEK.
Windows Information Protection – EFS generated self-signed cert for the public key of the public-private key pair generated for the user account used for protecting the FEK.

The certificate thumbprint is also added to registry under HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\EFS\CurrentKeys from where EFS makes use of it. You can see the same info using Cipher cmdline tool command cipher /y which shows you the public key cert thumbprint/cert hash currently used by EFS.

Windows Information Protection - Use Cipher cmdline tool to check the cert thumbprint used by EFS for file protection
Use Cipher cmdline tool to check the cert thumbprint used by EFS for file protection

Actual encryption workflow of EFS

  • A log file called Efs(x).log (x is unique number) is created in System Volume Information folder on the same drive, as the file to be encrypted.
  • NTFS sets the Encryption Flag and creates the $EFS attribute for the file to store the encryption information (DDF and DRF, explained in later steps)
  • EFS utilizes the CryptoAPI functionality of Windows to generate the symmetric key (FEK) for file content encryption/decryption.
  • EFS creates Data Decryption Field (DDF) within the $EFS attribute of the file. The FEK is encrypted with the public key certificate of the current signed-in user and placed in the DDF field.
  • If the WIP policy defines a Data Recovery Agent, EFS also creates Data Recovery Field (DRF) within the $EFS attribute, where it places the FEK which is encrypted with the DRA cert (public) as provided.
  • A temporary file Efs0.tmp is created in the same folder as the file being encrypted. The contents of original file (plain text) is copied into temporary file, after that the original is overwritten with encrypted data.
  • After encryption is done, temporary and log files are deleted.

This entire process happens in the backend and as such is transparent to the end user. File gets encrypted when it is closed and automatically decrypted if the current user account has the private key matching the public key. To check the entire process in details, please refer here.

EFS encryption with WIP is not same as EFS encryption in general (?)

On a Windows Information Protection enabled Windows 10 endpoint (both with and without enrollment) where you have not manually encrypted a file using EFS,

  • you will not find the self-signed cert in the User Personal Cert store. (there may be other user certs deployed by your organization reflecting here)
Windows Information Protection - No self-signed cert in User personal store is found for EFS purpose in a WIP enabled system where user has not manually encrypted a file with EFS.
Windows Information Protection – No self-signed cert in User personal store is found for EFS purpose in a WIP enabled system where user has not manually encrypted a file with EFS.
  • you will not see the CurrentKeys reg_key under  HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\EFS\ and instead will have only entries for EDPCredentials
Windows Information Protection - There is only EdpCredentials entry under EFS regsitry path. No EFS CurrentKeys entry.
Windows Information Protection – There is only EdpCredentials entry under EFS regsitry path. No EFS CurrentKeys entry.
  • you will not get any output if you run the command cipher /y to view the EFS cert thumbprint that EFS is currently using.

Let’s consider a WIP enabled system, where you have files manually encrypted via EFS as well. Below, you can see I have two files

  • one is WIP protected, and
  • other is EFS encrypted manually
Windows Information Protectetion - File Explorer showing a WIP protected file and a manual EFS encrypted file
Windows Information Protectetion – File Explorer showing a WIP protected file and a manual EFS encrypted file

See the difference in file ownership?

  • WIP protected file is tagged to the Enterprise Identity as defined in WIP policy for File Ownership
  • Manual EFS protected which shows the CN(SAN) of the EFS public key cert used for protecting the file

Using the EFSDump sysinternals tool to check the protection information of the files, you will see that for the

  •  WIP protected file, DDF field returned is empty.
  •  Manual EFS encrypted file, the DDF field has the value of the public key cert thumbprint.
Using EFSDump sysinternal tool to check the protection information - DDF returned is blank for a WIP protected file.
Using EFSDump sysinternal tool to check the protection information – DDF returned is blank for a WIP protected file.

Checking the protection info of the two files using Cipher utility

PS C:\Users\JoymalyaBasuRoy\Desktop\EFSDump> cipher /c .\Personal.txt
 
 Listing C:\Users\JoymalyaBasuRoy\Desktop\EFSDump\
 New files added to this directory will not be encrypted.
 
E Personal.txt
  Compatibility Level:
    Windows XP/Server 2003
 
  Users who can decrypt:
    AzureAD\JoymalyaBasuRoy [JoymalyaBasuRoy(JoymalyaBasuRoy@AzureAD)]
    Certificate thumbprint: C855 DD0A D5B4 70DE 1FB7 C580 ADFC F355 E82B 2367
 
  Recovery Certificates:
    JoymalyaBasuRoy(JoymalyaBasuRoy@AzureAD)
    Certificate thumbprint: E3B4 DCA2 D7EC E661 C8E7 EC5C D54B 5928 E0B8 F53B
 
  Key Information:
    Algorithm: AES
    Key Length: 256
    Key Entropy: 256
 
PS C:\Users\JoymalyaBasuRoy\Desktop\EFSDump> cipher /c .\work2.txt
 
 Listing C:\Users\JoymalyaBasuRoy\Desktop\EFSDump\
 New files added to this directory will not be encrypted.
 
E work2.txt
  Compatibility Level:
    Enterprise Protected
 
  Enterprise protected by:
    joymalya.com
 
  Recovery Certificates:
    JoymalyaBasuRoy(JoymalyaBasuRoy@AzureAD)
    Certificate thumbprint: E3B4 DCA2 D7EC E661 C8E7 EC5C D54B 5928 E0B8 F53B
 
  Key Information:
    Algorithm: AES
    Key Length: 256
    Key Entropy: 256

For the manual EFS encrypted file, you will get public cert details with which the file was encrypted. Using the Certutil tool, you can find out the corresponding private key details as shown below

PS Cert:\CurrentUser\My> $cert = gi cert:\CurrentUser\My\C855DD0AD5B470DE1FB7C580ADFCF355E82B2367
PS Cert:\CurrentUser\My> $cert | fl *
 
 
PSPath                   : Microsoft.PowerShell.Security\Certificate::CurrentUser\My\C855DD0AD5B470DE1FB7C580ADFCF355E8
                           2B2367
PSParentPath             : Microsoft.PowerShell.Security\Certificate::CurrentUser\My
PSChildName              : C855DD0AD5B470DE1FB7C580ADFCF355E82B2367
PSDrive                  : Cert
PSProvider               : Microsoft.PowerShell.Security\Certificate
PSIsContainer            : False
EnhancedKeyUsageList     : {Encrypting File System (1.3.6.1.4.1.311.10.3.4)}
DnsNameList              : {JoymalyaBasuRoy}
SendAsTrustedIssuer      : False
EnrollmentPolicyEndPoint : Microsoft.CertificateServices.Commands.EnrollmentEndPointProperty
EnrollmentServerEndPoint : Microsoft.CertificateServices.Commands.EnrollmentEndPointProperty
PolicyId                 :
Archived                 : False
Extensions               : {System.Security.Cryptography.Oid, System.Security.Cryptography.Oid,
                           System.Security.Cryptography.Oid}
FriendlyName             :
IssuerName               : System.Security.Cryptography.X509Certificates.X500DistinguishedName
NotAfter                 : 2/27/2120 6:54:09 PM
NotBefore                : 3/22/2020 6:54:09 PM
HasPrivateKey            : True
PrivateKey               : System.Security.Cryptography.RSACryptoServiceProvider
PublicKey                : System.Security.Cryptography.X509Certificates.PublicKey
RawData                  : {48, 130, 3, 25...}
SerialNumber             : 47DFA194526BE4AC4A62CF38C0B2D7D3
SubjectName              : System.Security.Cryptography.X509Certificates.X500DistinguishedName
SignatureAlgorithm       : System.Security.Cryptography.Oid
Thumbprint               : C855DD0AD5B470DE1FB7C580ADFCF355E82B2367
Version                  : 3
Handle                   : 1992566309712
Issuer                   : CN=JoymalyaBasuRoy
Subject                  : CN=JoymalyaBasuRoy
 
PS Cert:\CurrentUser\My> $cert.PrivateKey.CspKeyContainerInfo
 
 
MachineKeyStore        : False
ProviderName           : Microsoft Enhanced Cryptographic Provider v1.0
ProviderType           : 1
KeyContainerName       : c309ccd7-f8c6-4e7b-b4bf-6cc17b3fe76b
UniqueKeyContainerName : f9969d35521c72e688cffc35d6d9da2c_5f5f326a-34f7-469e-bdea-529234e0c80f
KeyNumber              : Exchange
Exportable             : True
HardwareDevice         : False
Removable              : False
Accessible             : True
Protected              : False
CryptoKeySecurity      : System.Security.AccessControl.CryptoKeySecurity
RandomlyGenerated      : False

Notice the CSP is Microsoft Enhanced Cryptographic Provider v1.0, a legacy CryptoAPI (CAPI) CSP (deprecated, for details check here) which implements both crypto algorithms and also provide key storage. CNG (CryptoAPI – Next Generation), the successor to CryptoAPI, separates cryptographic providers (implementation of algorithms) from key storage providers (KSP) services, providing better key isolation for protection.

The corresponding private key will be found at the user profile location  %APPDATA%\Microsoft\Crypto\RSA\{User SID}

Notice the filename of the key matches the Unique container name value as shown above.

EFS self generated Private key of the Private/Public key pair is stored at %APPDATA%\Microsoft\Crypto\RSA\{User SID}
EFS self generated Private key of the Private/Public key pair is stored at %APPDATA%\Microsoft\Crypto\RSA\{User SID}

This private key is turn protected by DPAPI using a symmetric key known as the User Master Key which is derived from the user logon credentials using some salt. The User Master Key itself is stored protected to the location %APPDATA%\Microsoft\Protect\{User SID}

If you go to the location as mentioned, you will see that the folder is empty. However, checking the folder properties will reveal that it actually contains files. (The files in this location are protected OS files)

In general, you would see 2 files here. This is because the User Master Key protected by the Protected Storage service is stored in two parts

Part 1 – the Password Encryption Key (PEK), is produced by the HMAC and SHA1 message digest function and is a hash of:

  • A symmetric encryption of the user’s master key produced by 160-bit RC4.
  • The user’s security identifier (SID).
  • The user’s logon password.

Part 2 – the backup/restore form of the master key, which is used in case, system fails to detect password changes and thereby fails to update the password encryption key, uses the backup to recover the previous key and regenerate Part 1.

For the WIP protected file, you will only see that it is enterprise protected, but it will not show you details of any cert with which the file was encrypted.

When WIP invokes EFS for file protection, EFS does not checks to see if there is a public/private key pair available in the User Personal cert store suitable to be used for EFS encryption. Even if there is one created by EFS for the current user account (in case you have manually encrypted files with EFS already), it won’t use it for file protection of WIP tagged file.

However, the file encryption process remains identical as explained above, in the sense, the file content gets encrypted using symmetric key which in turn is protected by an asymmetric key. The encryption key itself remains stored in the current user profile.

You can see the records for EDP Account that EFS will use at reg_path HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\EFS\EdpCredentials

Windows Information Protection - Corporate files are protected using the EDPCredemtial which is essentially against the Azure AD Identity
Windows Information Protection – Corporate files are protected using the EDPCredemtial which is essentially against the Azure AD Identity

In the event of unenrollment (or MDM handoff), the key still remains on the device, however, if policy is configured to revoke access for such events, the key become useless as it can’t be accessed to decrypt the FEK to decrypt the file content. In such cases, the encrypted files can only be recovered with a DRA cert if the WIP policy defined one.

The key information is at location %UserProfile%\AppData\Local\Microsoft\EDP\Recovery

If the same user enrolls back the device to management (for WIP with enrollment) or workplace joins the device back (for WIP without enrollment), access to the encryption key gets restored and the files can be accessed again.

EFS encryption – How secure is the protection?

As it is the public key of the public/private key pair generated for the current active user account which is used to protect the FEK, only the same user account will have access to the private key for decrypting the FEK.

For multiple users logging in to the same system, a unique RSA key pair is generated for each user account which are mutually non-accessible. Thus by default, only the user account under which the file protection activity was performed will have access to the file contents due to the possession of the private key. Other user accounts will be denied access to file contents as they won’t have access to the original account’s private key.

Microsoft recommends WIP to be used by single user per device – the account which enrolled the device. For multiple users signing in to same device (Azure AD join device), there may be inconsistency and service may fail to revoke access to encryption keys for secondary users.

To understand security of EFS file protection better, see the structure of the DDF field in the $EFS attribute of the file. (Explained in details here)

Windows Information Protection - Structure of $EFS attribute which stores the file  protection information
Windows Information Protection – Structure of $EFS attribute which stores the file protection information

The DDF field can have multiple DDF Key entries. By default, it will have a single DDF entry for the original user account. Each DDF key entry is identified by the User SID.

Consider a scenario where the system is compromised (lost or stolen) but the user account is not compromised.

In such case, if another user (attacker) creates a local account and tries to access EFS encrypted files present on the local disk, NTFS will get no match for the current user account SID against the SID value present in the DDF field of $EFS attribute of the protected file. NTFS will deny access to the file.

NTFS denies access to file if current User SID does not matches the User SID as present in the $EFS attribute of the file ensuring file access cannot be compromised
NTFS denies access to file if current User SID does not matches the User SID as present in the $EFS attribute of the file ensuring file access cannot be compromised

Even If the attacker decides to take the local disk out of the system and access the files from outside Windows, like attach it to another system running Linux to access the files, EFS has no 3rd party component driver support for other OS filesystem. Thus the file becomes useless to the attacker as it cannot be opened.

The only way to get to the content of an EFS encrypted file is, either

  • gain access to the user’s private key, the public key of which was used to protect the FEK (identified by the EFS cert hash in the DDF entry).

The private key is protected by the DPAPI master key which in turn is again protected by the user’s login credentials. A password change initiated from within the same user account session causes rekey/update of the DPAPI master key with the new user password, resulting rekeying of all the protected private keys which were protected by the previous version. Trying to reset the login credentials of the user account from outside the user account with special tools or from recovery environment will render it impossible to decrypt the DPAPI master key thereby securing the private key. As such, unless the original user account is compromised, the EFS encrypted files can’t be misused.

  • gain access to the DRA cert (private key) if the file has a DRF entry in the $EFS attribute, which is again quite impossible to gain access to.

However, once a user is logged on successfully, access to his own EFS encrypted data requires no additional authentication. Decryption happens transparently. Thus, any compromise of the user’s password automatically leads to access to that data.

Importance of DRA…

When WIP is enforced, work tagged data residing locally on an endpoint gets encrypted (EFS) using the WIP encryption key – an RSA public/private key pair generated locally on system for the Azure AD Identity under the authority of the current signed-in User Account.

Windows 10 version 1709 onwards, the WIP encryption key information gets automatically backed up to Azure against the Azure AD identity account(UPN).

If the WIP policy is configured to revoke encryption keys on unenrollment, MDM handoff, or if the device lost its encryption keys due to any unprecedented event, any such action would lead WIP protected data residing locally on the endpoint inaccessible.

Re-enrolling the device back with the same user identity causes Azure to restore the encryption key information on the endpoint making those protected files accessible again.

Still this is like a single point of failure and there maybe scenarios where re-enrolling the device with the same account is not an option. This is where a Data Recovery Agent certificate comes in handy. DRA is an RSA public/private key pair which can either be

  • requested from a CA (to support key archival), or
  • generated from a standalone device for a designated user account (maybe an EFS Recovery Service Account)

I will show the later as that is easier. For this, sign in to a standalone workstation with the designated user account and use the Cipher cmdline to command cipher /r:<Name for Cert Package>

Using cipher cmdline tool to generate a DRA certificate
Windows Information Protection – Using cipher cmdline tool to generate a DRA certificate

You will find two cert files in the current location.

  • .pfx contains the private key which can later be used for recovery purposes and as such should be backed up to a safe location, and
  • .cer which is the public key cert. (this is the one which needs to be added to the WIP policy to be distributed to the endpoints)

When a DRA cert is defined in the WIP policy, corporate tagged files are protected in a way that those can be accessed either by

  • the primary user, or
  • the IT admin having access to the private key of the DRA

For recovery using DRA, you would just need to import the private key to a system where you have admin rights. Also copy the encrypted inaccessible files to the same system. Then utilize the cipher utility to decrypt the encrypted file. 

WIP file protection is persistent when file moved/copied to removable media (?)

The Microsoft documentation for WIP states that file remains protected if copied to a USB drive.

However, this may or may not work as stated, since the protection status depends on the file system of the removable media. EFS is now supported with exFAT and FAT32 as well along with NTFS (default) however, is not supported with FAT and other filesystems.

To check if your removable media file format supports EFS, you can use the Windows fsutil cmdline tool command fsutil fsinfo volumeinfo <DriveLetter>:

Windows Information Protection - Check using FSUTIL cmdline tool if removable media file format supports EFS
Windows Information Protection – Check using FSUTIL cmdline tool if removable media file format supports EFS

If you check and see that the removable media supports EFS, when you try to move protected data from device local storage to a removable storage, you get a prompt similar to below

Windows Information Protection - Copy as work protected or personal? User can decide when copying to removable drive.
Windows Information Protection – Copy as work protected or personal? User can decide when copying to removable drive.

Let’s consider that you lost the USB drive, but if you have copied as Work Protected, you can be rest assured that others won’t be able to open the file to get the data/content.

WIP – Limitations (?)

By design, WIP is intended to protect work data at rest residing locally on an endpoint, and/or protect work data if copied over to a removable media like USB drive. However, WIP cannot protect work data in transit – when you attach a work file to an email or upload to a file share or online storage like SharePoint.

This limitation is due to the fact that WIP depends on EFS to protect data residing locally on an endpoint by encrypting and this protection information is not stored within the file, but as an attribute of the file (protection information resides on local disk separately, the location being pointed by the File Header which contains the $EFS attribute)

This is where Azure Information Protection integration with WIP comes to scenario, since AIP protection stays with the file irrespective of its location,

AIP protection information is basically defined in the file metadata rather than a file attribute which is a filesystem feature.

However, this cannot be termed as a limitation, if you see how Microsoft has positioned Windows Information Protection in its lineup of Information Protection offerings.

Windows Information Protection - How Microsoft has positioned WIP in the security stack
Windows Information Protection – How Microsoft has positioned WIP in the security stack

The main purpose of WIP is to differentiate and separate work data from personal data on an endpoint and prevent users from accidentally leaking work data to personal space.

And this is what Windows Information Protection does exactly – it does not tries to do what it was never supposed to do – protect data end-to-end throughout its lifecycle.

An Ending…

That was all that I had in store for you. Hope you all have liked the series and have learned something out of it which is the ultimate aim.

Stay tuned for a bonus article on Windows Information Protection – a complete troubleshooting guide for the Intune Admins out there.

Till then, read something everyday, learn something everyday but the most important of all – Stay Isolated, Stay Safe to help keep Others Safe!

6 COMMENTS

  1. Hey Joymalya,

    Awesome series on WIP – just finished going through it including the bonus on troubleshooting.

    Where I struggle with WIP is getting Azure RMS templates to protect USB files. My understanding is that when you copy a work file (EFS encrypted) to USB, it should let you copy, but protect it using the Azure RMS template you specify. However, in all my testing and configuration, I just get an error that reads I cannot place the file on the USB. The only way I’ve been able to do it is to not use Azure RMS, just EFS, but that means the USB cannot be shared with other users.

    Do you have any advice on troubleshooting such a problem?

    • Hi Ruairidh,

      Azure RMS (AIP) integration with WIP helps to protect file when it shared as an email attachment or uploaded to cloud locations or file servers.
      For USB, what error are you exactly getting. Is it completely blocking you to copy or it allows to copy by removing protection (depends on the file format of USB drive as it needs to support EFS).
      I haven’t heard or faced anything like that if you have azure RMS configured with WIP, you cannot copy to USB. The AIM of RMS is to keep the file protected irrespective of the file location as unlike WIP, where the EFS protection is applied as file attribute (function of file system), Azure RMS protection is built into the file metatdata and has no dependecy on the underlying filesystem.

      • Hey Joymalya, thanks for the reply. I can copy to the drive (NTFS) if I remove protection in the ‘allow overrides’ WIP method. Here’s exactly what happens recorded as a GIF – https://i.imgur.com/be0PxtL.gif

        The error for copying as work protected is simply the ‘organisation does not allow you to place this file here’. This is a clean system with only this app protection policy configured (no BitLocker USB requirements for example). Interestingly, when I copy as personal and then try to change ownership on the USB, it gives me error 0x80071787 (which returns no Google results) saying ‘specified file could not be encrypted with Windows Information Protection’. There are no logs in Event Viewer, and I have tried on MDM enrolled and MAM only PCs.

        I’ve confirmed in registry that the AIP template ID is retrieved but I get the feeling the problem is getting the AIP protection from the AIP service, but not sure. I even added a label policy to confirm permissions.

      • Hi Ruairidh,

        What is the output of fsutil fsinfo volumeinfo as example fsutil fsinfo volumeinfo D:
        Does is shows EFS as supported?
        You are unable to copy to USB drive either because your WIP policy defined EDP enforcement is set to Block or the USB drive itself does not supports EFS. Just a thought!

      • Hey Joymalya, thanks for the feedback. The output of dsutil looks fine as it reports “supports encrypted file system.” All very strange as I can copy and change to personal, so it’s definitely not in block mode either. I will keep investigating and update this thread if I find a solution.

  2. Hi Joymalya,

    great series regarding WIP!

    I have just one question. How is WIP working together with SMB File Shares? File Shares are not supporting EFS. What occurs if a users access data on a file share from an enterprise location? Are the data automated protected if accessed? Is it possible to disallow access from non WIP protected apps?

    Many Thanks,
    Markus

LEAVE A REPLY

Please enter your comment!
Please enter your name here

This site uses Akismet to reduce spam. Learn how your comment data is processed.