V Semester CSF

LeUNIT 4 PPT
MADE BY :YUVRAJ MEHRA
SAP ID :500106775

A data-centric view of cloud

security for IT Data
 Contents

• Definitions and terminology,

• Need for new methods,

• Cryptography,

• Data provenance,

• Privacy and security laws and regulations,

• Classification of data security issues in cloud computing,

• Cross-cutting issues,

• Nomad framework overview,

• Client management service,

• Cloud storage service,

• Operational overview,

• Homomorphic encryption background, BGV scheme, HElib,

• GPU-based acceleration of BGV FHE,

• Application: CallForFire, CallForFire operational workflow,

• Data security in cloud computing,

• Performance of the GPU-based parallelisation, CallForFire performance

 Definitions and terminology

•Title: Data Security in Cloud Computing and GPU-Accelerated FHE for Applications
•Subtitle: A Focus on Modern Methods and Applications
•Details: Your name, date, and organization/university.
 Definitions and terminology

• Cloud Workload Protection Program (CWPP): CWPPs help organizations

protect their capabilities or workloads (applications, resources, etc.) running in a
cloud instance.
• Container Security: A container represents a software application and may
contain all necessary code, run-time, system tools, and libraries needed to run the
application. Container hosts can be packed with risk, so properly securing them
means maintaining visibility into vulnerabilities associated with their components
and layers.
• Entitlements: Entitlements, or permissions entitlements, give domain users
control over basic users' and organization admins' permissions to access certain
parts of a tool.
 Definitions and terminology
• Agenda
• Definitions and Terminology
• Need for New Methods
• Cryptography
• Data Provenance
• Privacy and Security Laws and Regulations
• Classification of Data Security Issues in Cloud Computing
• Cross-Cutting Issues
• Overview of the Nomad Framework
• Homomorphic Encryption: BGV Scheme and GPU-Based Acceleration
• Application: CallForFire
• Performance and Conclusion
 Need for New Methods

• Need for New Methods

• Increasing complexity of cloud environments.
• Emergence of sophisticated cyber threats.
• Limitations of traditional encryption.
• Importance of privacy-preserving computation (e.g.,
homomorphic encryption).
 Need for new methods,
• Use multi-factor authentication: Require users to provide multiple forms of identification to access cloud services, such as a password,
smartphone, or biometric data.
• Implement encryption: Encrypt data in transit and at rest to protect sensitive information. You can use encrypted connections like
HTTPS, SSL, TLS, and FTPS.
• Use Identity and Access Management (IAM): Use IAM services to implement role-based access control (RBAC) and the principle of
least privilege. This limits user access to only the resources they need.
• Use cloud security posture management (CSPM): Use CSPM solutions to monitor for misconfigurations and evaluate your
deployments against best practices.
• Use virtual private clouds (VPCs): Use VPCs to create isolated, secure networks for sensitive assets.
• Use quantum-resistant encryption: Use post-quantum cryptography (PQC) algorithms to ensure long-term data security.
• Use secure VPNs: Use secure VPNs for remote access.
• Perform regular reviews: Regularly review and manage user access rights to identify and remove unnecessary permissions.
• Train employees: Train employees to increase awareness of cloud security threats.
• Manage vendor risk: Manage vendor risk to oversee third-party interactions.
• Perform patch management: Perform patch management to address vulnerabilities quickly.
Cryptography
Secure Communication
Needs and Requirements
• Well established needs for secure
communication
• War time communication
• Business transactions
• Illicit Love Affairs

• Requirements of secure communication

1. Secrecy
– Only intended receiver understands the message
2. Authentication
– Sender and receiver need to confirm each others identity
3. Message Integrity
– Ensure that their communication has not been altered,
either maliciously or by accident during transmission
Cryptography
Basics

• Cryptography is the science of secret, or

hidden writing
• It has two main Components:
1. Encryption
– Practice of hiding messages so that they can not be read
by anyone other than the intended recipient
2. Authentication & Integrity
– Ensuring that users of data/resources are the persons
they claim to be and that a message has not been
surreptitiously altered
Encryption
Cipher
• Cipher is a method for encrypting messages

Plain Text Encryption Cipher Text Decryption Plain Text

Algorithm Algorithm

Key A Key B

• Encryption algorithms are standardized & published

• The key which is an input to the algorithm is secret
• Key is a string of numbers or characters
• If same key is used for encryption & decryption the algorithm is called
symmetric
• If different keys are used for encryption & decryption the algorithm is
called asymmetric
Encryption
Symmetric Algorithms

• Algorithms in which the key for encryption and

decryption are the same are Symmetric
• Example: Caesar Cipher

• Types:
1. Block Ciphers
– Encrypt data one block at a time (typically 64 bits, or
128 bits)
– Used for a single message
2. Stream Ciphers
– Encrypt data one bit or one byte at a time
– Used if data is a constant stream of information
Symmetric Encryption
Key Strength
• Strength of algorithm is determined by the size of the
key
• The longer the key the more difficult it is to crack

• Key length is expressed in bits

• Typical key sizes vary between 48 bits and 448 bits

• Set of possible keys for a cipher is called key space

• For 40-bit key there are 240 possible keys
• For 128-bit key there are 2128 possible keys
• Each additional bit added to the key length doubles the security

• To crack the key the hacker has to use brute-force

(i.e. try all the possible keys till a key that works is found)
• Super Computer can crack a 56-bit key in 24 hours
• It will take 272 times longer to crack a 128-bit key
(Longer than the age of the universe)
Substitution Ciphers
Caesar Cipher

• Caesar Cipher is a method in which each letter

in the alphabet is rotated by three letters as
shown
ABCDEFGHIJKLMNOPQRSTUVWXYZ

DEFGHIJKLMNOPQRSTUVWXYZABC

• Let us try to encrypt the message

– Attack at Dawn
Assignment: Each student will exchange a
secret message with his/her closest neighbor
about some other person in the class and the
neighbor will decipher it.
Substitution Ciphers
Caesar Cipher
Encryption
Plain Text Cipher Text
Cipher:
Message: Caesar Cipher Message:
Attack at Dawn Algorithm Dwwdfn Dw Gdyq

Key (3)
Decrypti
on
Cipher Text Plain Text
Cipher:
Message: Caesar Cipher Message:
Dwwdfn Dw Gdyq Algorithm Attack at Dawn

Key (3)

How many different keys are possible?

Substitution Cipher
Monoalphabetic Cipher

• Any letter can be substituted for any other letter

• Each letter has to have a unique substitute
ABCDEFGH I JKLMNOPQRSTUVWXYZ

MNBVCXZASDFGHJ KLPO IUYTREWQ

• There are 26! pairing of letters (~1026)

• Brute Force approach would be too
Message:
time consuming
Encrypted
Message:
• Alice
Cipher:
Statistical Analysis would make it feasible to crack the
Bob, I love you. Monoalphabetic Nkn, s gktc wky.
mgsbc
key Cipher

Key
 Substitution Cipher
Polyalphabetic Caesar Cipher

• Developed by Blaise de Vigenere

• Also called Vigenere cipher

• Uses a sequence of monoalpabetic ciphers in

tandem
Plain Text ABCDEFGH I JKLMNOPQRSTUVWXYZ
• e.g. C1, C2, C2, C1, C2

C1(k=6) FGH I JKLMNOPQRSTUVWXYZABCDE

C2(k=20) TUVWXYZABCDEFGH I JKLMNOPQRS

Message: Encrypted
Cipher: Message:
Bob, I love you. Monoalphabetic Gnu, n etox dhz.

• Alice
Example Cipher tenvj

Key
 Substitution Cipher
Using a key to shift alphabet
• Obtain a key to for the algorithm and then shift the alphabets
• For instance if the key is word we will shift all the letters by four and remove
the letters w, o, r, & d from the encryption
• We have to ensure that the mapping is one-to-one
• no single letter in plain text can map to two different letters in cipher text
• no single letter in cipher text can map to two different letters in plain text

Plain Text ABCDEFGH I JKLMNOPQRSTUVWXYZ

C1(k=6) WORDABCEFGH I JKLMNPQSTUVXY

Z
Message:
Encrypted
Cipher: Message:
Bob, I love you.
??
Alice

WORD
Transposition Cipher
Columnar Transposition
• This involves rearrangement of characters on the plain text into columns
• The following example shows how letters are transformed
• If the letters are not exact multiples of the transposition size there may be a
few short letters in the last column which can be padded with an infrequent
letter such as x or z

Plain Text Cipher Text

T H I S I T S S O H
S A M E S O A N I W
S A G E T H A A S O
O S H O W L R S T O
H O W A C I M G H W
O L U M N U T P I R
A R T R A S E E O A
N S P O S M R O O K
I T I O N I S T W C
W O R K S N A S N S
Ciphers
Shannon’s Characteristics of “Good” Ciphers

• The amount of secrecy needed should

determine the amount of labor appropriate for
the encryption and decryption.
• The set of keys and the enciphering algorithm
should be free from complexity.
• The implementation of the process should be
as simple as possible.
• Errors in ciphering should not propagate and
cause corruption of further information in the
message.
• The size of the enciphered text should be no
larger than the text of the original message.
Encryption Systems
Properties of Trustworthy Systems
• It is based on sound mathematics.
• Good cryptographic algorithms are are derived
from solid principles.

• It has been analyzed by competent experts

and found to be sound.
• Since it is hard for the writer to envisage all
possible attacks on the algorithm

• It has stood the “test of time.”

• Over time people continue to review both
mathematical foundations of an algorithm and the
way it builds upon those foundations.
• The flaws in most algorithms are discovered soon
after their release.
Cryptanalysis
Techniques
• Cryptanalysis is the process of breaking an encryption
code
• Tedious and difficult process

• Several techniques can be used to deduce the algorithm

• Attempt to recognize patterns in encrypted messages, to be
able to break subsequent ones by applying a straightforward
decryption algorithm
• Attempt to infer some meaning without even breaking the
encryption, such as noticing an unusual frequency of
communication or determining something by whether the
communication was short or long
• Attempt to deduce the key, in order to break subsequent
messages easily
• Attempt to find weaknesses in the implementation or
environment of use of encryption
• Attempt to find general weaknesses in an encryption algorithm,
without necessarily having intercepted any messages
Data Encryption Standard (DES) Basics
• Goal of DES is to completely scramble the
data and key so that every bit of cipher text
depends on every bit of data and ever bit of
key
• DES is a block Cipher Algorithm
• Encodes plaintext in 64 bit chunks
• One parity bit for each of the 8 bytes thus it reduces
to 56 bits

• It is the most used algorithm

• Standard approved by US National Bureau of
Standards for Commercial and nonclassified US
government use in 1993
Data Encryption Standard (DES) Basics
64-bit input 56-bit key

48-bit k1
L1 R1 • DES run in reverse to
decrypt
F(L1, R1, K1)

48-bit k2
• Cracking DES
L2 R2
• 1997: 140 days
F(L2, R2, K2) • 1999: 14 hours

L3 R3
48-bit k3 • TripleDES uses DES 3
times in tandem
• Output from 1 DES is
input to next DES
F(L16, R16, K16)

48-bit k16
L17 R17
Encryption Algorithm
Summary

Algorithm Type Key Size Features

DES Block 56 bits Most Common, Not

Cipher strong enough
TripleDES Block 168 bits Modification of DES,
Cipher (112 effective) Adequate Security
Blowfish Block Variable Excellent Security
Cipher (Up to 448 bits)
AES Block Variable Replacement for DES,
Cipher (128, 192, or Excellent Security
256 bits)
RC4 Stream Variable Fast Stream Cipher,
Cipher (40 or 128 bits) Used in most SSL
implementations
Symmetric Encryption
Limitations

• Any exposure to the secret key compromises

secrecy of ciphertext
• A key needs to be delivered to the recipient of
the coded message for it to be deciphered
• Potential for eavesdropping attack during
transmission of key
Asymmetric Encryption
Basics
• Uses a pair of keys for encryption
• Public key for encryption
• Private key for decryption

• Messages encoded using public key can only be decoded by the

private key
• Secret transmission of key for decryption is not required
• Every entity can generate a key pair and release its public key

Plain Text Cipher Text Plain Text

Cipher Cipher

Public Key Private Key

Asymmetric Encryption
Types

• Two most popular algorithms are RSA & El

Gamal
• RSA
• Developed by Ron Rivest, Adi Shamir, Len Adelman
• Both public and private key are interchangable
• Variable Key Size (512, 1024, or 2048 buts)
• Most popular public key algorithm
• El Gamal
• Developed by Taher ElGamal
• Variable key size (512 or 1024 bits)
• Less common than RSA, used in protocols like PGP
Asymmetric Encryption
RSA
• Choose two large prime numbers p & q
• Compute n=pq and z=(p-1)(q-1)
• Choose number e, less than n, which has no common
factor (other than 1) with z
• Find number d, such that ed – 1 is exactly divisible by z
• Keys are generated using n, d, e
• Public key is (n,e)
• Private key is (n, d)
• Encryption: c = me mod n
• m is plain text
• c is cipher text
• Decryption: m = cd mod n
• Public key is shared and the private key is hidden
Asymmetric Encryption
RSA
• P=5 & q=7
• n=5*7=35 and z=(4)*(6) = 24
• e=5
• d = 29 , (29x5 –1) is exactly divisible by 24
• Keys generated are
• Public key: (35,5)
• Private key is (35, 29)

• Encrypt the word love using (c = me mod n)

• Assume that the alphabets are between 1 & 26

Plain Text Numeric Representation me Cipher Text (c = me mod

n)
l 12 248832 17
o 15 759375 15
v 22 5153632 22
e 5 3125 10
Asymmetric Encryption
RSA

• Decrypt the word love using (m = cd mod n)

Cipher
Text
• c
n = 35, c=29
d
(m = me mod
n)
Plain
Text
17 481968572106750915091411825223072000 17 l
15 12783403948858939111232757568359400 15 o
22 85264331908653770195619449972111000000 22 v
0
10 100000000000000000000000000000 10 e
Asymmetric Encryption
Weaknesses

• Efficiency is lower than Symmetric

Algorithms
• A 1024-bit asymmetric key is equivalent to 128-bit
symmetric key

• Potential for man-in-the middle attack

• It is problematic to get the key pair
generated for the encryption
Asymmetric Encryption
Man-in-the-middle Attack
• Hacker could generate a key pair, give the public key away
and tell everybody, that it belongs to somebody else. Now,
everyone believing it will use this key for encryption,
resulting in the hacker being able to read the messages. If
he encrypts the messages again with the public key of the
real recipient, he will not be recognized easily.
Trudeau’s Trudeau’s
Bob
Message Encrypted
+ public key Cipher Message
David’s
Public Key

David’s
Bob’s Bob’s Public Key
Message Trudeau
Cipher Encrypted David
+ Public key (Middle-man)
Message

Bob’s Attacker Trudeau’s

Public Key Public Key

Trudeau’s David’s
Trudeau’s Trudeau’s
New Message Message
Encrypted Cipher + public key Encrypted Cipher + public key
Message Message
Asymmetric Encryption
Session-Key Encryption
• Used to improve efficiency
• Symmetric key is used for encrypting data
• Asymmetric key is used for encrypting the symmetric key

Plain Text Cipher Cipher Text

(DES)

Send to Recipient

Encrypted
Cipher Key
(RSA)
Session Key

Recipient’s Public Key

Asymmetric Encryption
Encryption Protocols
• Pretty Good Privacy (PGP)
• Used to encrypt e-mail using session key encryption
• Combines RSA, TripleDES, and other algorithms

• Secure/Multipurpose Internet Mail Extension (S/MIME)

• Newer algorithm for securing e-mail
• Backed by Microsoft, RSA, AOL

• Secure Socket Layer(SSL) and Transport Layer Socket(TLS)

• Used for securing TCP/IP Traffic
• Mainly designed for web use
• Can be used for any kind of internet traffic
Asymmetric Encryption
• Agreement
Key Key agreement is a method to create secret key by
exchanging only public keys.
• Example
• Bob sends Alice his public key
• Alice sends Bob her public key
• Bob uses Alice’s public key and his private key to generate
a session key
• Alice uses Bob’s public key and her private key to generate
a session key
• Using a key agreement algorithm both will generate same
Alice’s
key Private Key

•
Bob’s Bob and Alice do not need to transfer any key
Cipher
Public Key
(DES) Alice and Bob
Bob’s Session Key
Generate Same
Private Key Session Key!
Alice’s Cipher
Public Key
(DES)
Asymmetric Encryption
Key Diffie-Hellman Mathematical Analysis
Bob & Alice
Bob agree on non-secret Alice
prime p and value a

Generate Secret Generate Secret

Random Number x Random Number y

Bob & Alice

Compute Public Key exchange Compute Public Key
ax mod p public keys ay mod p

Compute Session Key Compute Session Key

(ay)x mod p (ax)y mod p

Identical Secret Key

Asymmetric Encryption
Key Agreement con’t.

• Diffie-Hellman is the first key agreement

algorithm
• Invented by Whitfield Diffie & Martin Hellman
• Provided ability for messages to be exchanged
securely without having to have shared some secret
information previously
• Inception of public key cryptography which allowed
keys to be exchanged in the open

• No exchange of secret keys

• Man-in-the middle attack avoided
Authentication
Basics

• Authentication is the process of validating the

identity of a user or the integrity of a piece of
data.
• There are three technologies that provide
authentication
• Message Digests / Message Authentication Codes
• Digital Signatures
• Public Key Infrastructure

• There are two types of user authentication:

• Identity presented by a remote or application
participating in a session
• Sender’s identity is presented along with a message.
Authentication
Message Digests
• A message digest is a fingerprint for a document
• Purpose of the message digest is to provide proof that
data has not altered
• Process of generating a message digest from data is
called hashing
• Hash functions are one way functions with following
properties
• Infeasible to reverse the function
• Infeasible to construct two messages which hash to same digest

• Commonly used hash algorithms are

• MD5 – 128 bit hashing algorithm by Ron Rivest of RSA
• SHA & SHA-1 – 162 bit hashing algorithm developed by NIST

Message Message Digest

Digest
Algorithm
Message Authentication Codes
Basics

• A message digest created with a key

• Creates security by requiring a secret key to be
possesses by both parties in order to retrieve
the message

Message
Message Digest Digest
Algorithm

Secret Key
Password Authentication
Basics
• Password is secret character string only known
to user and server
• Message Digests commonly used for password
authentication
• Stored hash of the password is a lesser risk
• Hacker can not reverse the hash except by brute
force attack

• Problems with password based authentication

• Attacker learns password by social engineering
• Attacker cracks password by brute-force and/or
guesswork
• Eavesdrops password if it is communicated
unprotected over the network
• Replays an encrypted password back to the
Authentication Protocols
Basics
• Set of rules that governs the communication of data related to authentication
between the server and the user
• Techniques used to build a protocol are
• Transformed password
• Password transformed using one way function before transmission
• Prevents eavesdropping but not replay

• Challenge-response
• Server sends a random value (challenge) to the client along with the
authentication request. This must be included in the response
• Protects against replay

• Time Stamp
• The authentication from the client to server must have time-stamp embedded
• Server checks if the time is reasonable
• Protects against replay
• Depends on synchronization of clocks on computers

• One-time password
• New password obtained by passing user-password through one-way function n
times which keeps incrementing
• Protects against replay as well as eavesdropping
Authentication Protocols
Kerberos

• Kerberos is an authentication service that uses

symmetric key encryption and a key
distribution center.
• Kerberos Authentication server contains
symmetric keys of all users and also contains
information on which user has access privilege
to which services on the network
Authentication
Personal Tokens
• Personal Tokens are hardware devices that generate
unique strings that are usually used in conjunction with
passwords for authentication
• Different types of tokens exist
• Storage Token: A secret value that is stored on a token and is
available after the token has been unlocked using a PIN
• Synchronous one-time password generator: Generate a new
password periodically (e.g. each minute) based on time and a
secret code stored in the token
• Challenge-response: Token computes a number based on a
challenge value sent by the server
• Digital Signature Token: Contains the digital signature private
key and computes a computes a digital signature on a supplied
data value

• A variety of different physical forms of tokens exist

• e.g. hand-held devices, Smart Cards, PCMCIA cards, USB
tokens
Authentication
Biometrics
• Uses certain biological characteristics for
authentication
• Biometric reader measures physiological indicia and
compares them to specified values
• It is not capable of securing information over the
network

• Different techniques exist

• Fingerprint Recognition
• Voice Recognition
• Handwriting Recognition
• Face Recognition
• Retinal Scan
• Hand Geometry Recognition
Authentication
Iris Recognition
The scanning process takes advantage of
the natural patterns in people's irises,
digitizing them for identification
purposes

Facts
• Probability of two irises producing exactly the
same code: 1 in 10 to the 78th power
• Independent variables (degrees of freedom)
extracted: 266
• IrisCode record size: 512 bytes
• Operating systems compatibility: DOS and
Windows (NT/95)
• Average identification speed (database of
100,000 IrisCode records): one to two seconds
 Authentication
Digital Signatures
• A digital signature is a data item which
accompanies or is logically associated with a
digitally encoded message.
• It has two goals
• A guarantee of the source of the data
• Proof that the data has not been tampered with
Sender’s Sender’s
Private Key Public Key

Message Digest Digest Message

Sent to Algorithm Algorithm Digest
Receiver

Same?

Digital
Message Signature Signature Signature Message
Digest Algorithm Sent to Algorithm Digest
Receiver

Sender Receiver
Authentication
Digital Cerftificates
• A digital certificate is a signed statement by a trusted party that
another party’s public key belongs to them.
• This allows one certificate authority to be authorized by a different
authority (root CA)
• Top level certificate must be self signed
• Any one can start a certificate authority
• Name recognition is key to some one recognizing a certificate authority
• Verisign is industry standard certificate authority
Identity
Information

Signature Certificate
Sender’s
Algorithm
Public Key

Certificate
Authority’s
Private Key
Authentication
• ChainingChaining
Cerftificates is the practice of signing a certificate with
another private key that has a certificate for its public
key
• Similar to the passport having the seal of the government
• It is essentially a person’s public key & some identifying
information signed by an authority’s private key
verifying the person’s identity
• The authorities public key can be used to decipher the
certificate
• The trusted party isSignature
Certificate
called the certificate authority
New Certificate
Algorithm

Certificate
Authority’s
Private Key
Cryptanalysis
Basics
• Practice of analyzing and breaking cryptography
• Resistance to crypt analysis is directly proportional to
the key size
• With each extra byte strength of key doubles

• Cracking Pseudo Random Number Generators

• A lot of the encryption algorithms use PRNGs to generate keys
which can also be cracked leading to cracking of algorithms

• Variety of methods for safe guarding keys (Key

Management)
• Encryption & computer access protection
• Smart Cards
Data provenance,
 Infrastructure Security

• Network Level
• Host Level
• Application Level

53
 The Network Level

• Ensuring confidentiality and integrity of your organization’s

data-in-transit to and from your public cloud provider
• Ensuring proper access control (authentication, authorization,
and auditing) to whatever resources you are using at your
public cloud provider
• Ensuring availability of the Internet-facing resources in a public
cloud that are being used by your organization, or have been
assigned to your organization by your public cloud providers
• Replacing the established model of network zones and tiers
with domains
From [6] Cloud Security and Privacy by Mather and
Kumaraswamy
54
 The Network Level - Mitigation

• Note that network-level risks exist regardless of what aspects

of “cloud computing” services are being used
• The primary determination of risk level is therefore not which
*aaS is being used,
• But rather whether your organization intends to use or is
using a public, private, or hybrid cloud.

From [6] Cloud Security and Privacy by Mather and

Kumaraswamy
55
 The Host Level

• SaaS/PaaS
• Both the PaaS and SaaS platforms abstract and hide the host OS from
end users
• Host security responsibilities are transferred to the CSP (Cloud Service
Provider)
• You do not have to worry about protecting hosts
• However, as a customer, you still own the risk of managing
information hosted in the cloud services.
From [6] Cloud Security and Privacy by Mather and
Kumaraswamy
56
 The Host Level (cont.)

• IaaS Host Security

• Virtualization Software Security
• Hypervisor (also called Virtual Machine Manager (VMM)) security is a key
• a small application that runs on top of the physical machine H/W layer
• implements and manages the virtual CPU, virtual memory, event channels, and memory shared by the
resident VMs
• Also controls I/O and memory access to devices.
• Bigger problem in multitenant architectures
• Customer guest OS or Virtual Server Security
• The virtual instance of an OS
• Vulnerabilities have appeared in virtual instance of an OS
• e.g., VMWare, Xen, and Microsoft’s Virtual PC and Virtual Server
• Customers have full access to virtual servers.

57
From [6] Cloud Security and Privacy by Mather and
 Case study: Amazon's EC2
infrastructure
• “Hey, You, Get Off of My Cloud: Exploring Information Leakage in Third-Party Compute
Clouds”
• Multiple VMs of different organizations with virtual boundaries separating each VM can
run within one physical server
• "virtual machines" still have internet protocol, or IP, addresses, visible to anyone
within the cloud.
• VMs located on the same physical server tend to have IP addresses that are close to
each other and are assigned at the same time
• An attacker can set up lots of his own virtual machines, look at their IP addresses, and
figure out which one shares the same physical resources as an intended target
• Once the malicious virtual machine is placed on the same server as its target, it is
possible to carefully monitor how access to resources fluctuates and thereby
potentially glean sensitive information about the victim

58
 Local Host Security

• Are local host machines part of the cloud infrastructure?

• Outside the security perimeter
• While cloud consumers worry about the security on the cloud
provider’s site, they may easily forget to harden their own machines
• The lack of security of local devices can
• Provide a way for malicious services on the cloud to attack local
networks through these terminal devices
• Compromise the cloud and its resources for other users
 Local Host Security (Cont.)

• With mobile devices, the threat may be even stronger

• Users misplace or have the device stolen from them
• Security mechanisms on handheld gadgets are often times insufficient compared to say, a
desktop computer
• Provides a potential attacker an easy avenue into a cloud system.
• If a user relies mainly on a mobile device to access cloud data, the threat to availability is
also increased as mobile devices malfunction or are lost
• Devices that access the cloud should have
• Strong authentication mechanisms
• Tamper-resistant mechanisms
• Strong isolation between applications
• Methods to trust the OS
• Cryptographic functionality when traffic confidentiality is required

60
 The Application Level

• DoS
• EDoS(Economic Denial of Sustainability)
• An attack against the billing model that underlies the cost of
providing a service with the goal of bankrupting the service itself.
• End user security
• Who is responsible for Web application security in the cloud?
• SaaS/PaaS/IaaS application security
• Customer-deployed application security
From [6] Cloud Security and Privacy by Mather and
Kumaraswamy
61
 Data Security and Storage

• Several aspects of data security, including:

• Data-in-transit
• Confidentiality + integrity using secured protocol
• Confidentiality with non-secured protocol and encryption
• Data-at-rest
• Generally, not encrypted , since data is commingled with other users’ data
• Encryption if it is not associated with applications?
• But how about indexing and searching?
• Then homomorphic encryption vs. predicate encryption?
• Processing of data, including multitenancy
• For any application to process data, not encrypted

From [6] Cloud Security and Privacy by Mather and

62 Kumaraswamy
 Data Security and Storage (cont.)
• Data lineage Where is (or was) that system located?
• Knowing when and where
What was the the
state ofdata wassystem?
that physical located w/i
cloud is importantHow
forwould
audit/compliance purposes
a customer or auditor verify that
• e.g., Amazon AWSinfo?
• Store <d1, t1, ex1.s3.amazonaws.com>
• Process <d2, t2, ec2.compute2.amazonaws.com>
• Restore <d3, t3, ex2.s3.amazonaws.com>
• Data provenance
• Computational accuracy (as well as data integrity)
• E.g., financial calculation: sum ((((2*3)*4)/6) -2) =
$2.00 ?
• Correct : assuming US dollar
• How about dollars of different countries?
• Correct exchange rate?
From [6] Cloud Security and Privacy by Mather and
63 Kumaraswamy
 Data Security and Storage

• Data remanence
• Inadvertent disclosure of sensitive information is possible
• Data security mitigation?
• Do not place any sensitive data in a public cloud
• Encrypted data is placed into the cloud?
• Provider data and its security: storage
• To the extent that quantities of data from many companies are centralized, this collection
can become an attractive target for criminals
• Moreover, the physical security of the data center and the trustworthiness of system
administrators take on new importance.

From [6] Cloud Security and Privacy by Mather and

64 Kumaraswamy
 Why IAM?

• Organization’s trust boundary will become dynamic and will move beyond the control and
will extend into the service provider domain.
• Managing access for diverse user populations (employees, contractors, partners, etc.)
• Increased demand for authentication
• personal, financial, medical data will now be hosted in the cloud
• S/W applications hosted in the cloud requires access control
• Need for higher-assurance authentication
• authentication in the cloud may mean authentication outside F/W
• Limits of password authentication
• Need for authentication from mobile devices

From [6] Cloud Security and Privacy by Mather and

Kumaraswamy
65
 IAM considerations

• The strength of authentication system should be reasonably balanced with

the need to protect the privacy of the users of the system
• The system should allow strong claims to be transmitted and verified w/o
revealing more information than is necessary for any given transaction or
connection within the service
• Case Study: S3 outage
• authentication service overload leading to unavailability
• 2 hours 2/15/08
• http://www.centernetworks.com/amazon-s3-downtime-update

66
 What is Privacy?

• The concept of privacy varies widely among (and sometimes within) countries,
cultures, and jurisdictions.
• It is shaped by public expectations and legal interpretations; as such, a concise
definition is elusive if not impossible.
• Privacy rights or obligations are related to the collection, use, disclosure,
storage, and destruction of personal data (or Personally Identifiable Information
—PII).
• At the end of the day, privacy is about the accountability of organizations to data
subjects, as well as the transparency to an organization’s practice around
personal information.

67 From [6] Cloud Security and Privacy by Mather and

Kumaraswamy
 What is the data life cycle?

• Personal information should be

managed as part of the data used
by the organization
• Protection of personal information
should consider the impact of the
cloud on each phase
68 From [6] Cloud Security and Privacy by Mather and
Kumaraswamy
 What Are the Key Privacy Concerns?

• Typically mix security and privacy

• Some considerations to be aware of:
• Storage
• Retention
• Destruction
• Auditing, monitoring and risk management
• Privacy breaches
• Who is responsible for protecting privacy?

69 From [6] Cloud Security and Privacy by Mather and

Kumaraswamy
 Storage

• Is it commingled with information from other organizations that use the

same CSP?
• The aggregation of data raises new privacy issues
• Some governments may decide to search through data without necessarily notifying
the data owner, depending on where the data resides

• Whether the cloud provider itself has any right to see and access
customer data?
• Some services today track user behaviour for a range of purposes, from
sending targeted advertising to improving services

70 From [6] Cloud Security and Privacy by Mather and

Kumaraswamy
 Retention

• How long is personal information (that is transferred to the

cloud) retained?
• Which retention policy governs the data?
• Does the organization own the data, or the CSP?
• Who enforces the retention policy in the cloud, and how are
exceptions to this policy (such as litigation holds) managed?

From [6] Cloud Security and Privacy by Mather and

71
Kumaraswamy
• How does the cloud provider destroy PII at the end of the
retention period? Destruction
• How do organizations ensure that their PII is destroyed by
the CSP at the right point and is not available to other
cloud users?
• Cloud storage providers usually replicate the data across
multiple systems and sites—increased availability is one of
the benefits they provide.
• How do you know that the CSP didn’t retain additional
copies?
• Did the CSP really destroy the data, or just make it
inaccessible to the organization?
• Is the CSP keeping the information longer than
necessary so that it can mine the data for its own use?
72 From [6] Cloud Security and Privacy by Mather and
Kumaraswamy
 Auditing, monitoring and risk
management
• How can organizations monitor their CSP and provide assurance to
relevant stakeholders that privacy requirements are met when their PII is
in the cloud?
• Are they regularly audited?
• What happens in the event of an incident?
• If business-critical processes are migrated to a cloud computing model,
internal security processes need to evolve to allow multiple cloud
providers to participate in those processes, as needed.
• These include processes such as security monitoring, auditing, forensics, incident
response, and business continuity

73 From [6] Cloud Security and Privacy by Mather and

Kumaraswamy
 Privacy breaches

• How do you know that a breach has occurred?

• How do you ensure that the CSP notifies you when a breach occurs?
• Who is responsible for managing the breach notification process (and
costs associated with the process)?
• If contracts include liability for breaches resulting from negligence of
the CSP?
• How is the contract enforced?
• How is it determined who is at fault?

74 From [6] Cloud Security and Privacy by Mather and

Kumaraswamy
 Who is responsible for protecting
privacy?
e.g., Suppose a hacker breaks into Cloud Provider A and steals data from Company X.
Assume that the compromised server also contained data from Companies Y and Z.

• Who investigates this crime?

• Is it the Cloud Provider, even though Company X may fear that
the provider will try to absolve itself from responsibility?
• Data breaches have
• Is it Company aif cascading
X and, so, does it have theeffect
right to see other data on that server,

• including logs that may show access to the data of Companies Y and Z?
Full reliance on a third party to protect personal data?
• In-depth understanding of responsible data stewardship
• Organizations can transfer liability, but not accountability
• Risk assessment and mitigation throughout the data life cycle is critical.
• Many new risks and unknowns
• The overall complexity of privacy protection in the cloud represents a bigger
challenge.

75 From [6] Cloud Security and Privacy by Mather and

Kumaraswamy
 Outline — Introduction to Privacy in
Computing
1) Introduction (def., dimensions, basic principles, …)
2) Recognition of the need for privacy
3) Threats to privacy
4) Privacy Controls
4.1) Technical privacy controls - Privacy-Enhancing Technologies (PETs)
a) Protecting user identities
b) Protecting usee identities
c) Protecting confidentiality & integrity of personal data
4.2) Legal privacy controls
a) Legal World Views on Privacy
b) International Privacy Laws: Comprehensive or Sectoral
c) Privacy Law Conflict between European Union – USA
d) A Common Approach: Privacy Impact Assessments (PIA)
e) Observations & Conclusions

5) Selected Advanced Topics in Privacy

5.1) Privacy in pervasive computing
5.2) Using trust paradigm for privacy protection
5.3) Privacy metrics
 1. Introduction (1) [cf. Simone Fischer-Hübner]

• Def. of privacy [Alan Westin, Columbia University, 1967]

= the claim of individuals, groups and institutions to

determine for themselves, when, how and to what
extent information about them is communicated to
others

• 3 dimensions of privacy:
1) Personal privacy
Protecting a person against undue interference (such as physical
searches) and information that violates his/her moral sense
2) Territorial privacy
Protecting a physical area surrounding a person that may not
be violated without the acquiescence of the person
• Safeguards: laws referring to trespassers search warrants
3) Informational privacy
Deals with the gathering, compilation and selective
 1. Introduction (2) [cf. Simone Fischer-Hübner]

• Basic privacy principles

• Lawfulness and fairness
• Necessity of data collection and processing
• Purpose specification and purpose binding
• There are no "non-sensitive" data
• Transparency
• Data subject´s right to information correction, erasure or blocking of
incorrect/ illegally stored data
• Supervision (= control by independent data protection authority) & sanctions
• Adequate organizational and technical safeguards

• Privacy protection can be undertaken by:

• Privacy and data protection laws promoted by government
• Self-regulation for fair information practices by codes of conducts
promoted by businesses
• Privacy-enhancing technologies (PETs) adopted by individuals
• Privacy education of consumers and IT professionals
 2. Recognition of Need for Privacy
Guarantees (1)

• By individuals [Cran et al. ‘99]

• 99% unwilling to reveal their SSN

• 18% unwilling to reveal their… favorite TV show

• By businesses
• Online consumers worrying about revealing personal data
held back $15 billion in online revenue in 2001

• By Federal government
• Privacy Act of 1974 for Federal agencies
• Health Insurance Portability and Accountability Act of 1996
(HIPAA)
 2. Recognition of Need for Privacy Guarantees (2)

• By computer industry research (examples)

• Microsoft Research
• The biggest research challenges:
According to Dr. Rick Rashid, Senior Vice President for Research

• Reliability / Security / Privacy / Business Integrity

• Broader: application integrity (just “integrity?”)

=> MS Trustworthy Computing Initiative

• Topics include: DRM—digital rights management (incl. watermarking

surviving photo editing attacks), software rights protection,
intellectual property and content protection, database privacy and
p.-p. data mining, anonymous e-cash, anti-spyware

• IBM (incl. Privacy Research Institute)

• Topics include: pseudonymity for e-commerce, EPA and EPAL—
enterprise privacy architecture and language, RFID privacy, p.-p.
video surveillance, federated identity management (for enterprise
federations), p.-p. data mining and p.-p.mining of association rules,
hippocratic (p.-p.) databases, online privacy monitoring
 2. Recognition of Need for Privacy Guarantees (3)

• By academic researchers (examples from the U.S.A.)

• CMU and Privacy Technology Center
• Latanya Sweeney (k-anonymity, SOS—Surveillance of Surveillances,
genomic privacy)
• Mike Reiter (Crowds – anonymity)

• Purdue University – CS and CERIAS

• Elisa Bertino (trust negotiation languages and privacy)
• Bharat Bhargava (privacy-trust tradeoff, privacy metrics, p.-p. data
dissemination, p.-p. location-based routing and services in networks)
• Chris Clifton (p.-p. data mining)
• Leszek Lilien (p.-p. data disemination)

• UIUC
• Roy Campbell (Mist – preserving location privacy in pervasive computing)
• Marianne Winslett (trust negotiation w/ controled release of private
credentials)

• U. of North Carolina Charlotte

• Xintao Wu, Yongge Wang, Yuliang Zheng (p.-p. database testing and data
mining)
 3. Threats to Privacy (1) [cf. Simone Fischer-Hübner]

1) Threats to privacy at application level

 Threats to collection / transmission of large
quantities of personal data
• Incl. projects for new applications on Information Highway,
e.g.:
• Health Networks / Public administration Networks
• Research Networks / Electronic Commerce / Teleworking
• Distance Learning / Private use

• Example: Information infrastructure for a better healthcare

[cf. Danish "INFO-Society 2000"- or Bangemann-Report]

• National and European healthcare networks for the

interchange of information
• Interchange of (standardized) electronic patient case files
• Systems for tele-diagnosing and clinical treatment
 3. Threat to Privacy (2) [cf. Simone
Fischer-Hübner]

2) Threats to privacy at communication level

• Threats to anonymity of sender / forwarder / receiver

• Threats to anonymity of service provider

• Threats to privacy of communication

• E.g., via monitoring / logging of transactional data
• Extraction of user profiles & its long-term storage

3) Threats to privacy at system level

• E.g., threats at system access level

4) Threats to privacy in audit trails

 3. Threat to Privacy (3) [cf. Simone
Fischer-Hübner]

• Identity theft – the most serious crime against privacy

• Threats to privacy – another view

• Aggregation and data mining
• Poor system security
• Government threats
• Gov’t has a lot of people’s most private data
• Taxes / homeland security / etc.
• People’s privacy vs. homeland security concerns
• The Internet as privacy threat
• Unencrypted e-mail / web surfing / attacks
• Corporate rights and private business
• Companies may collect data that U.S. gov’t is not allowed to
• Privacy for sale - many traps
• “Free” is not free…
• E.g., accepting frequent-buyer cards reduces your privacy
 4. Privacy Controls

1) Technical privacy controls - Privacy-Enhancing

Technologies (PETs)

a) Protecting user identities

b) Protecting usee identities
c) Protecting confidentiality & integrity of personal data

2) Legal privacy controls

 4.1. Technical Privacy Controls (1)

 Technical controls - Privacy-Enhancing Technologies

(PETs)
[cf. Simone Fischer-Hübner]

a) Protecting user identities via, e.g.:

• Anonymity - a user may use a resource or service without
disclosing her identity
• Pseudonymity - a user acting under a pseudonym may use
a resource or service without disclosing his identity
• Unobservability - a user may use a resource or service
without others being able to observe that the resource or
service is being used
• Unlinkability - sender and recipient cannot be identified as
communicating with each other
 4.1. Technical Privacy Controls (2)

 Taxonomies of pseudonyms [cf. Simone Fischer-

Hübner]

 Taxonomy of pseudonyms w.r.t. their function

i) Personal pseudonyms
• Public personal pseudonyms / Nonpublic personal pseudonyms /
Private personal pseudonyms
ii) Role pseudonyms
• Business pseudonyms / Transaction pseudonyms

 Taxonomy of pseudonyms w.r.t. their generation

i) Self-generated pseudonyms
ii) Reference pseudonyms
iii) Cryptographic pseudonyms
iv) One-way pseudonyms
 4.1. Technical Privacy Controls (3)

b) Protecting user identities via, e.g.: [cf. Simone Fischer-

Hübner]

Depersonalization (anonymization) of data subjects

• Perfect depersonalization:
• Data rendered anonymous in such a way that the data subject
is no longer identifiable

• Practical depersonalization:
• The modification of personal data so that the information
concerning personal or material circumstances can no longer
or only with a disproportionate amount of time, expense and
labor be attributed to an identified or identifiable individual

• Controls for depersonalization include:

• Inference controls for statistical databases
• Privacy-preserving methods for data mining
 4.1. Technical Privacy Controls (4)

• The risk of reidentification (a threat to anonymity)

[cf. Simone Fischer-Hübner]

• Types of data in statistical records:

• Identity data - e.g., name, address, personal number
• Demographic data - e.g., sex, age, nationality
• Analysis data - e.g., diseases, habits

• The degree of anonymity of statistical data depends on:

• Database size
• The entropy of the demographic data attributes that can serve as
supplementary knowledge for an attacker

• The entropy of the demographic data attributes depends on:

• The number of attributes
• The number of possible values of each attribute
• Frequency distribution of the values
• Dependencies between attributes
 4.1. Technical Privacy Controls (5)

c) Protecting confidentiality and integrity of personal

data via, e.g.:
[cf. Simone Fischer-Hübner]

• Privacy-enhanced identity management

• Limiting access control
• Incl. formal privacy models for access control
• Enterprise privacy policies
• Steganography
• Specific tools
• Incl. P3P (Platform for Privacy Preferences)
 4.2. Legal Privacy Controls (1)

• Outline
a) Legal World Views on Privacy
b)International Privacy Laws:
• Comprehensive Privacy Laws
• Sectoral Privacy Laws

c) Privacy Law Conflict European Union vs. USA

d) A Common Approach: Privacy Impact Assessments (PIA)
e) Observations & Conclusions
 4.2. Legal Privacy Controls (2)

a) Legal World Views on Privacy (1)

[cf. A.M. Green, Yale, 2004]

• General belief:Privacy is a fundamental

human right that has become one of the most
important rights of the modern age

• Privacy also recognized and protected by

individual countries
• At a minimum each country has a provision for rights
of inviolability of the home and secrecy of
communications
• Definitions of privacy vary according to context and
environment
 4.2. Legal Privacy Controls (3)
a) Legal World Views on Privacy (2)
[A.M. Green, Yale, 2004]

United States: “Privacy is the right to be left alone”

- Justice Louis Brandeis

UK: “the right of an individual to be protected

against intrusion into his personal life or affairs by
direct physical means or by publication of
information

Australia: “Privacy is a basic human right and the

reasonable expectation of every person”
 4.2. Legal Privacy Controls (4)
b) International Privacy Laws
• [cf. A.M. Green, Yale, 2004]
Two types of privacy laws in various countries:
1) Comprehensive Laws
• Def: General laws that govern the collection, use and
dissemination of personal information by public & private
sectors
• Require commissioners or independent enforcement body
• Difficulty: lack of resources for oversight and
enforcement; agencies under government control
• Examples: European Union, Australia, Canada and the UK

2) Sectoral Laws
• Idea: Avoid general laws, focus on specific sectors instead
• Advantage: enforcement through a range of mechanisms
• Disadvantage: each new technology requires new
legislation
 4.2. Legal Privacy Controls (5) -- b) International Privacy Laws
Comprehensive Laws - European Union

• European Union Council adopted the new Privacy Electronic Communications

Directive [cf. A.M. Green, Yale, 2004]

• Prohibits secondary uses of data without informed consent

• No transfer of data to non EU countries unless there is adequate privacy protection
• Consequences for the USA

• EU laws related to privacy include

• 1994 — EU Data Protection Act
• 1998 — EU Data Protection Act
• Privacy protections stronger than in the U.S.
 [cf. A.M. Green, Yale, 2004]

• No explicit right
4.2. Legal toControls
Privacy privacy (6) --in
b) the constitution
International Privacy Laws

• Limited Sectoral
constitutional Laws right- United
to privacy States
implied (1) in
number of provisions in the Bill of Rights

• A patchwork of federal laws for specific categories of

personal information
• E.g., financial reports, credit reports, video rentals, etc.

• No legal protections, e.g., for individual’s privacy on

the internet are in place (as of Oct. 2003)
• White House and private sector believe that self-
regulation is enough and that no new laws are
needed (exception: medical records)

• Leads to conflicts with other countries’ privacy

policies
• American lawsPrivacy
4.2. Legal related to privacy
Controls include: Privacy Laws
(7) -- b) International
• Sectoral
1974 — Laws
US Privacy Act - United States (2)
• Protects privacy of data collected by the executive branch of
federal gov’t
• 1984 — US Computer Fraud and Abuse Act
• Penalties: max{100K, stolen value} and/or 1 to 20 yrs
• 1986 — US Electronic Communications Privacy Act
• Protects against wiretapping
• Exceptions: court order, ISPs
• 1996 — US Economic Espionage Act
• 1996 — HIPAA
• Privacy of individuals’ medical records
• 1999 — Gramm-Leach-Bliley Act
• Privacy of data for customers of financial institutions
• 2001 — USA Patriot Act
• — US Electronic Funds Transfer Act
• — US Freedom of Information Act
 [cf. A.M. Green, Yale, 2004]

• US lobbied EU for4.2.2 Legal

years (1998-2000)
Privacy to convince it
Controls (8)
c)that the USLaw
Privacy system is adequate
Conflict: EU vs. The United States
• Result was the “Safe Harbor Agreement” (July 2000):
US companies would voluntarily self-certify to adhere
to a set of privacy principles worked out by US
Department of Commerce and Internal Market
Directorate of the European Commission
• Little enforcement: A self-regulatory system in which
companies merely promise not to violate their declared
privacy practices
• Criticized by privacy advocates and consumer groups in
both US and Europe

• Agreement re-evaluated in 2003

• Main issue: European Commission doubted effectiveness of
the sectoral/self-regulatory approach
 4.2. Legal Privacy Controls (9)
d) A Common Approach:
Privacy Impact Assessments[cf.(PIA) (1)
A.M. Green, Yale, 2004]

• An evaluation conducted to assess how the adoption of new information policies, the
procurement of new computer systems, or the initiation of new data collection programs
will affect individual privacy

• The premise: Considering privacy issues at the early stages of a project cycle will reduce
potential adverse impacts on privacy after it has been implemented

• Requirements:
• PIA process should be independent
• PIA performed by an independent entity (office and/or commissioner) not linked to the project under
review
• Participating countries: US, EU, Canada, etc.
 4.2. Legal Privacy Controls (10)
d) A Common Approach: PIA (2)

[cf. A.M. Green, Yale, 2004]

• EU implemented PIAs

• Under the European Union Data Protection Directive, all EU members must
have an independent privacy enforcement body

• PIAs soon to come to the United States (as of 2003)

• US passed the E-Government Act of 2002 which requires federal agencies

to conduct privacy impact assessments before developing or procuring
information technology
 4.2. Legal Privacy Controls (11)

e) Observations and Conclusions

[cf. A.M. Green, Yale, 2004]

• Observation 1: At present too many mechanisms seem to operate on a national or regional,

rather than global level
• E.g., by OECD

• Observation 2: Use of self-regulatory mechanisms for the protection of online activities seems
somewhat haphazard and is concentrated in a few member countries

• Observation 3: Technological solutions to protect privacy are implemented to a limited extent

only

• Observation 4: Not enough being done to encourage the implementation of technical solutions
for privacy compliance and enforcement
• Only a few member countries reported much activity in this area
 4.2. Legal Privacy Controls (12)
e) Observations and Conclusions
[cf. A.M. Green, Yale, 2004]

• Conclusions
• Still work to be done to ensure the security of personal information for
all individuals in all countries

• Critical that privacy protection be viewed in a global perspective

• Better than a purely national one –
To better handle privacy violations that cross national borders
 [cf. A.M. Green, Yale, 2004]

5. Selected Advanced Topics in Privacy (1)

Outline

5.1) Privacy in pervasive computing

5.2) Using trust paradigm for privacy protection
5.3) Privacy metrics
5.4) Trading privacy for trust
 5. Selected Advanced Topics in Privacy
5.1. Privacy in Pervasive Computing
(1)

• In pervasive computing environments, socially-based paradigms

(incl. trust) will play a big role

• People surrounded by zillions of computing devices of all kinds,

sizes, and aptitudes [“Sensor Nation: Special Report,” IEEE Spectrum, vol. 41, no. 7, 2004 ]

• Most with limited / rudimentary capabilities

• Quite small, e.g., RFID tags, smart dust
• Most embedded in artifacts for everyday use, or even human bodies
• Possible both beneficial and detrimental (even apocalyptic) consequences

• Danger of malevolent opportunistic sensor networks

— pervasive devices self-organizing into huge spy networks
• Able to spy anywhere, anytime, on everybody and everything
• Need means of detection & neutralization
• To tell which and how many snoops are active, what data they collect, and who
they work for
• An advertiser? a nosy neighbor? Big Brother?
• Questions such as “Can I trust my refrigerator?” will not be jokes
• The refrigerator snitching on its owner’s dietary misbehavior for her doctor
 5.1. Privacy in Pervasive Computing (2)

• Will pervasive computing destroy privacy? (as we know it)

• Will a cyberfly end privacy?
• With high-resolution camera eyes and supersensitive microphone ears
• If a cyberfly too clever drown in the soup, we’ll build cyberspiders
• But then opponents’ cyberbirds might eat those up
• So, we’ll build a cybercat
• And so on and so forth …

• Radically changed reality demands new approaches to privacy

• Maybe need a new privacy category—namely, artifact privacy?

• Our belief: Socially based paradigms (such as trust-based approaches) will play
a big role in pervasive computing
• Solutions will vary (as in social settings)
• Heavyweighty solutions for entities of high intelligence and capabilities (such as
humans and intelligent systems) interacting in complex and important matters

• Lightweight solutions for less intelligent and capable entities interacting in simpler
matters of lesser consequence
 5. Selected Advanced Topics in Privacy

5.2. Using Trust for Privacy Protection (1)

• Privacy = entity’s ability to control the availability and

exposure of information about itself
• We extended the subject of privacy from a person in the original
definition [“Internet Security Glossary,” The Internet Society, Aug.
2004 ] to an entity— including an organization or software
• Controversial but stimulating
• Important in pervasive computing

• Privacy and trust are closely related

• Trust is a socially-based paradigm
• Privacy-trust tradeoff: Entity can trade privacy for a
corresponding gain in its partners’ trust in it

• The scope of an entity’s privacy disclosure should be proportional

to the benefits expected from the interaction
• As in social interactions
• E.g.: a customer applying for a mortgage must reveal much more
personal data than someone buying a book
 5.2. Using Trust for Privacy Protection (2)

• Optimize degree of privacy traded to gain trust

• Disclose minimum needed for gaining partner’s necessary trust level

• To optimize, need privacy & trust measures

Once measures available:
• Automate evaluations of the privacy loss and trust gain
• Quantify the trade-off
• Optimize it

• Privacy-for-trust trading requires privacy guarantees for

further dissemination of private info
• Disclosing party needs satisfactory limitations on further
dissemination (or the lack of thereof) of traded private information
• E.g., needs partner’s solid privacy policies
• Merely perceived danger of a partner’s privacy violation can make the
disclosing party reluctant to enter into a partnership
• E.g., a user who learns that an ISP has carelessly revealed any customer’s
email will look for another ISP
 5.2. Using Trust for Privacy Protection (3)

• Conclusions on Privacy and Trust

• Without privacy guarantees, there can be no trust and
trusted interactions
• People will avoid trust-building negotiations if their privacy is
threatened by the negotiations
• W/o trust-building negotiations no trust can be established
• W/o trust, there are no trusted interactions

• Without privacy guarantees, lack of trust will cripple the

promise of pervasive computing
• Bec. people will avoid untrusted interactions with privacy-
invading pervasive devices / systems
• E.g., due to the fear of opportunistic sensor networks
Self-organized by electronic devices around us – can harm people in
their midst

• Privacy must be guaranteed for trust-building negotiations

 5. Selected Advanced Topics in Privacy

5.3. Privacy Metrics (1)

Outline

• Problem and Challenges

• Requirements for Privacy Metrics
• Related Work
• Proposed Metrics
A.Anonymity set size metrics
B.Entropy-based metrics
 5.3. Privacy Metrics (2)

a) Problem and Challenges

• Problem
• How to determine that certain degree of data
privacy is provided?

• Challenges
• Different privacy-preserving techniques or systems
claim different degrees of data privacy

• Metrics are usually ad hoc and customized

• Customized for a user model
• Customized for a specific technique/system

• Need to develop uniform privacy metrics

• To confidently compare different techniques/systems
 5.3. Privacy Metrics (3a)

b) Requirements for Privacy Metrics

• Privacy metrics should account for:

• Dynamics of legitimate users
• How users interact with the system?
E.g., repeated patterns of accessing the same data can leak
information to a violator
• Dynamics of violators
• How much information a violator gains by watching the system
for a period of time?
• Associated costs
• Storage, injected traffic, consumed CPU cycles, delay
 5.3. Privacy Metrics (3b)

c) Related Work

• Anonymity set without accounting for probability

distribution [Reiter and Rubin, 1999]

• An entropy metric to quantify privacy level,

assuming static attacker model [Diaz et al., 2002]

• Differential entropy to measure how well an

attacker estimates an attribute value [Agrawal and
Aggarwal 2001]
 5.3. Privacy Metrics (4)

d) Proposed Metrics

A. Anonymity set size metrics

B. Entropy-based metrics
 5.3. Privacy Metrics (5)

A. Anonymity Set Size Metrics

• The larger set of indistinguishable entities, the lower

probability of identifying any one of them
• Can use to ”anonymize” a selected private attribute value
within the domain of its all possible values

“Hiding in a
crowd”

“Less” anonymous (1/4)

“More” anonymous (1/n)

 5.3. Privacy Metrics (6)

Anonymity Set

• Anonymity set A
A = {(s1, p1), (s2, p2), …, (sn, pn)}
• si: subject i who might access private data
or: i-th possible value for a private data attribute
• pi: probability that si accessed private data
or: probability that the attribute assumes the i-th
possible value
 5.3. Privacy Metrics (7)

Effective Anonymity Set Size

| A|

L | A |  min(
• Effective anonymity set size
p i ,1is/ | A |)
i 1

• Maximum value of L is |A| iff all pi’’s are equal to 1/|A|

• L below maximum when distribution is skewed
• skewed when pi’’s have different values

• Deficiency:
L does not consider violator’s learning behavior
 5.3. Privacy Metrics (8)

B. Entropy-based Metrics

• Entropy measures the randomness, or uncertainty, in private

data
• When a violator gains more information, entropy decreases
• Metric: Compare the current entropy value with its maximum
value
• The difference shows how much information has been leaked
 5.3. Privacy Metrics (9)

Dynamics of Entropy

• Decrease of system entropy with attribute disclosures

(capturing dynamics)

H*

Entrop
y
Level

Disclosed All
attributes attribut
(a es (b (c) (d
) ) )
• When entropy reaches a threshold (b), data evaporation can be
invoked to increase entropy by controlled data distortions
• When entropy drops to a very low level (c), apoptosis can be triggered
to destroy private data
• Entropy increases (d) if the set of attributes grows or the disclosed
attributes become less valuable – e.g., obsolete or more data now
 5.3. Privacy Metrics (10)

Quantifying Privacy Loss

• Privacy loss D(A,t) at time t, when a subset of

attribute values A might have been disclosed:
D( A, t ) H * ( A)  H ( A, t )

• H*(A) – the maximum entropy

• Computed when probability distribution of pi’s is uniform

• H(A,t) is entropy at time t

| A|
 
H A, t    wj   pi log2 pi 

j 1  i 

• wj – weights capturing relative privacy “value” of attributes

 5.3. Privacy Metrics (11)

Using Entropy in Data Dissemination

• Specify two thresholds for D

• For triggering evaporation
• For triggering apoptosis

• When private data is exchanged

• Entropy is recomputed and compared to the thresholds
• Evaporation or apoptosis may be invoked to enforce privacy
 5.3. Privacy Metrics (12)

Entropy: Example

• Consider a private phone number: (a1a2a3) a4a5 a6 – a7a8a9 a10

• Each digit is stored as a value of a separate attribute
• Assume:
• Range of values for each attribute is [0—9]
• All attributes are equally important, i.e., wj = 1

• The maximum entropy – when violator has no information

about the value of each attribute:
• Violator assigns a uniform probability distribution to
values of each attribute
• e.g., a1= i with probability of 0.10 for each i in [0—9]
9
 10

*
 
H ( A)   w j
j 0  i 1
 0.1 log2 0.1 33.3

 5.3. Privacy Metrics (13)

Entropy: Example – cont.

• Suppose that after time t, violator can figure out the state of
the phone number, which may allow him to learn the three
10
 9
leftmost digits 
 
H A, t  0  w j   0.1 log2 0.1 23.3
j 4  •
i 0 Entropy at time t is given by:

• Attributes a1, aD2,Aa,3t contribute

H * A  H0Ato
, t the
10entropy
.0 value because
violator knows their correct values
• Information loss at time t is:
 Security Issues in Cloud
Computing :

Interference of Hackers and Insecure

API’s –
Data Loss – As we know, if we are talking about the cloud
Data Loss is one of the issues faced in Cloud and its services it means we are talking about
Computing. This is also known as Data the Internet. Also, we know that the easiest
Leakage. As we know that our sensitive data way to communicate with Cloud is using API.
is in the hands of Somebody else, and we So it is important to protect the Interface’s and
don’t have full control over our database. So, if API’s which are used by an external user. But
the security of cloud service is to break by also in cloud computing, few services are
hackers then it may be possible that hackers available in the public domain which are the
will get access to our sensitive data or vulnerable part of Cloud Computing because it
personal files. may be possible that these services are
accessed by some third parties. So, it may be
possible that with the help of these services
hackers can easily hack or harm our data.
3.User Account Hijacking –
Account Hijacking is the most serious security issue in Cloud
Computing. If somehow the Account of User or an Organization is
hijacked by a hacker then the hacker has full authority to perform
Unauthorized Activities.

4.Changing Service Provider –

Vendor lock-In is also an important Security issue in Cloud
Computing. Many organizations will face different problems while
shifting from one vendor to another. For example, An Organization
wants to shift from AWS Cloud to Google Cloud Services then they
face various problems like shifting of all data, also both cloud
services have different techniques and functions, so they also face
problems regarding that. Also, it may be possible that the charges
of AWS are different from Google Cloud, etc.
5.Lack of Skill –
While working, shifting to another service provider, need an
extra feature, how to use a feature, etc. are the main problems
caused in IT Companies who doesn’t have skilled Employees.
So it requires a skilled person to work with Cloud Computing.

6.Denial of Service (DoS) attack –

This type of attack occurs when the system receives too much
traffic. Mostly DoS attacks occur in large organizations such as
the banking sector, government sector, etc. When a DoS
attack occurs, data is lost. So, in order to recover data, it
requires a great amount of money as well as time to handle it.
7.Shared Resources: Cloud computing relies on a shared infrastructure.
If one customer’s data or applications are compromised, it may
potentially affect other customers sharing the same resources, leading
to a breach of confidentiality or integrity.
8.Compliance and Legal Issues: Different industries and regions have
specific regulatory requirements for data handling and storage. Ensuring
compliance with these regulations can be challenging when data is
stored in a cloud environment that may span multiple jurisdictions.
9.Data Encryption: While data in transit is often encrypted, data at rest
can be susceptible to breaches. It’s crucial to ensure that data stored in
the cloud is properly encrypted to prevent unauthorized access.
10.Insider Threats: Employees or service providers with access to cloud
systems may misuse their privileges, intentionally or unintentionally
causing data breaches. Proper access controls and monitoring are
essential to mitigate these threats.
11.Data Location and Sovereignty: Knowing where your data
physically resides is important for compliance and security. Some
cloud providers store data in multiple locations globally, and this may
raise concerns about data sovereignty and who has access to it.
12.Loss of Control: When using a cloud service, you are entrusting a
third party with your data and applications. This loss of direct control
can lead to concerns about data ownership, access, and availability.
13.Incident Response and Forensics: Investigating security
incidents in a cloud environment can be complex. Understanding what
happened and who is responsible can be challenging due to the
distributed and shared nature of cloud services.
14.Data Backup and Recovery: Relying on cloud providers for data
backup and recovery can be risky. It’s essential to have a robust
backup and recovery strategy in place to ensure data availability in
case of outages or data loss.
15.Vendor Security Practices: The security practices of cloud
service providers can vary. It’s essential to thoroughly assess the
security measures and certifications of a chosen provider to
ensure they meet your organization’s requirements.
16.IoT Devices and Edge Computing: The proliferation of IoT
devices and edge computing can increase the attack surface.
These devices often have limited security controls and can be
targeted to gain access to cloud resources.
17.Social Engineering and Phishing: Attackers may use social
engineering tactics to trick users or cloud service providers into
revealing sensitive information or granting unauthorized access.
18.Inadequate Security Monitoring: Without proper monitoring
and alerting systems in place, it’s challenging to detect and
respond to security incidents in a timely manner.
 Nomad: A Framework for Developing
Mission-Critical Cloud-based Applications
• Nomad, a framework for developing mission-critical cloud-based applications. The framework is
comprised of: 1) a homomorphic encryption-based service for processing encrypted data
directly within the untrusted cloud infrastructure, and 2) a client service for encrypting and
decrypting data within the trusted environment, and storing and retrieving these data to and
from the cloud. Both services are equipped with GPU-based parallelization to accelerate the
expensive homomorphic encryption operations
1. Developed a fully homomorphic encryption-based key/value storage system. This storage
provides a means for efficient access and processing of encrypted data stored in the cloud.
2. Designed a framework, called Nomad, around the storage system, which facilitates the
development of mission-critical applications that can be deployed in the cloud. The framework
simplifies the development of secure applications within different domains.
3. Used GPU parallelization to accelerate HElib operations on both the trusted client and the
cloudbased untrusted server. The current release of HElib is still slow for practical applications.
Acceleration of HElib operations makes applications using HElib more practical.
4. Implemented CallForFire, an interactive GIS application that demonstrates the feasibility of the
Nomad framework.
5. Performed experiments analyzing the performance of the CallForFire application. For
interactive applications such as CallForFire, Homomorphic Encryption is feasible, but may still
be too slow for non-interactive applications.
• The design of the framework is
based on the client/server
architecture paradigm. The
design is modular, which
provides for extensibility and
customization. Figure 1 shows
the high-level architecture of
the framework, which comprises
two main components: the
Client Management Service and
the Cloud Storage Service
 Client Management Service
• The Client Management Service provides the userfacing interface to the system, including the
client management and graphical user interfaces.
• The Client Management Service consists of multiple components, as seen in Figure 1. The Client
Management Engine coordinates the client operations such as encryption, decryption,
homomorphic arithmetic operations, key generation, and key management.
• The client-side HE Processing Engine is used for encrypting and decrypting application data.
After homomorphic encryption is performed on the data, the public key needs to be sent along
with the ciphertext to the server so that the server-side HE Processing Engine can perform re-
encryption of the ciphertext as necessary.
• On the server side, HElib must occasionally perform reencryption (i.e., bootstrapping) of the
ciphertext in order to maintain data integrity as homomorphic operations are performed on the
ciphertext.
• The client-side HE Key Manager generates public/private key pairs used for
encryption/decryption of the plaintext data, and interfaces with the Public/Private Key Store to
retrieve the keys when performing encryption and decryption.
• The Public/Private Key Store is used for storing both the public and private keys associated with
each user of the system. The Client API is used for exposing these services, and the Cloud
Monitor GUI is used for visually monitoring the health status of the virtual machines in the cloud.
 . Cloud Storage Service
• The Cloud Storage Service provides mechanisms to enable trusted ’store and compute’
services on untrusted infrastructure environments.
• The Cloud Storage Engine coordinates all of the operations of the Cloud Storage Service
and provides the server-side interface to the storage system.
• The cloud service provider’s underlying Hypervisor manages multiple Virtual Machines
(VMs) which hosts the services orchestrated by the application server.
• The Monitor tracks the resource usage of these VMs and archives the data in the Dom
Stats DB (i.e., the domain statistics database).
• The server-side HE Processing Engine is used for performing homomorphic arithmetic
operations (e.g., addition, subtraction, multiplication) on the homomorphically encrypted
data, for performing HE key generation, for performing multi-level encryption/decryption
of the ciphertext, and for running the underlying HElib functions used in performing these
higher level operations.
• The HE Processing Engine pushes the output of HE operations into the Ciphertext Store.
The Ciphertext Store is also responsible for storing the original ciphertext provided by the
client. The server-side HE Key Manager maintains the public key associated with each
ciphertext data element stored in the Ciphertext Store
 Nomad Operational Overview

• The basic operations of the Nomad framework are

• storing data,
• retrieving data,
• deleting data,
• performing operations on the data. In this
 Nomad Operational Overview

• At a high level, the client application uses a Client API to make use
of the Cloud Storage Service.
• The Client Management Service manages all of the keys, data,
and operations on behalf of the client.
• The Cloud Storage Service hosts the application server and the
Cloud Storage Engine.
• The application data is stored and processed in the cloud in
encrypted form, then returned to the client application for display
to the end-user.
 Nomad Operational Overview

• When first using the system, the user must initialize the client and
generate their own public/private key pair (Keypublic, Keyprivate).
 Nomad Operational Overview
• Data Storage Workflow:
• 1) System Initialization: Upon first using the system, the user sends a request to the
Client Management Engine to generate a public/private key pair (< IDuser,
Keypublic, Keyprivate >). The Client Management Engine then asks the HE Key
Manager to generate the key pair and store it in the Public/Private Key Store. The
Client Management Engine also sends the User ID and Public Key (< IDuser,
Keypublic >) to the Cloud Storage Engine for later usage. The Cloud Storage Engine
calls on the HE Key Manager to store the User ID and Public Key in the Public Key
Store.
• 2) The user initiates a request to store their Dataplaintext in the cloud storage
• 3) The Client Management Engine submits a request to encrypt the data to get the
ciphertext (Enc(Dataplaintext, Keypublic) = Dataciphertext).
• 4) The Client Management Engine submits a request to the server to store the
ID/data pair (< IDuser,IDdata, Dataciphertext >).
• 5) The Cloud Storage Engine receives the storage request and calls on the HE
Processing Engine to store the data (< IDdata, Dataciphertext >) in the Ciphertext
Store.
 HE Operation Workflow
1. 1) The user requests an operation (e.g., addition) to be performed on two integers (e.g., data1
and data2).
2. 2) The Client Management Engine generates a request and sends it to the Cloud Storage Engine
(< IDuser,IDdata1,IDdata2, Operation >).
3. 3) The Cloud Storage Engine parses the request to identify the operation.
4. 4) The Cloud Storage Engine retrieves the two data elements from the Ciphertext Store using
their associated data IDs (IDdata1 and IDdata2).
5. 5) The Cloud Storage Engine retrieves the Public Key associated with the user’s ID (IDuser) from
the Public Key Store.
6. 6) The Cloud Storage Engine calls on the HE Processing Engine to compute the addition
operation on the ciphertext data (Add(Keypublic, Dataciphertext1, Dataciphertext2) =
Resultciphertext).
7. 7) The Cloud Storage Engine returns Resultciphertext to the Client Management Engine.
8. 8) The Client Management Engine calls on the HE Key Manager to retrieve the user’s private key.
9. 9) The Client Management Engine calls on the HE Processing Engine to decrypt the
Resultciphertext (Dec(Keyprivate, Resultciphertext) = Resultplaintext).
10.10) The Client Management Engine sends the Resultplaintext to the user.
 . FULLY HOMOMORPHIC ENCRYPTION

• Fully Homomorphic Encryption (FHE) has long been viewed as the

holy grail of cryptography. The ability to outsource data processing
without giving away information about the data, or which
components of the data are of interest during computation, is
foundational for the concepts of security and privacy in the cloud.
 FULLY HOMOMORPHIC ENCRYPTION

• Fully Homomorphic Encryption (FHE) has long been viewed as the

holy grail of cryptography. The ability to outsource data processing
without giving away information about the data, or which
components of the data are of interest during computation, is
foundational for the concepts of security and privacy in the cloud.
 Brakerski, Gentry, and Vaikuntanathan (BGV) Scheme

• The BVG scheme for homomorphic encryption is based on the Ring Learning
With Errors (RLWE) problem and is built on algebraic structures, in particular
rings and ideal lattices.
• The security of RLWE schemes is based on the Shortest Vector Problem (SVP),
which has been shown to be at least as hard as worst-case lattice problems.
RLWE schemes are generally more computationally efficient than traditional
LWE because of the use of ideal lattices as the mathematical structure.
• BGV offers a choice of “leveled” FHE schemes based on either LWE or RLWE,
with the RLWE scheme having better performance. “Leveled” FHE means that
the size of the public key is linear in the depth of the circuits that the scheme
can evaluate, that is, its size is not constant.
• The key operation in the scheme is the REFRESH procedure, which switches
the moduli of the lattice structure and switches the key. In fact, with RLWE this
process runs in almost quasilinear time.
 Brakerski, Gentry, and Vaikuntanathan (BGV) Scheme

• as follows: For security parameter λ, let f(x) = xd + 1 where d =

d(λ) is a power of 2. Let q = q(λ) ≥ 2 be an integer.
• Let R = Z[x]/(f(x)) and let Rq = R/qR. Let χ = χ(λ) be a distribution
over R.
• The RLW Ed,q,χ problem is to distinguish the following two
distributions: In the first distribution, one samples (ai, bi) from R2 q.
• In the second distribution, one first draws s ← Rq uniformly and
then samples (ai, bi) ∈ R2 q by sampling ai ← (R)q uniformly, ei ←
χ, and setting bi = ai · s + ei.
• The assumption is that the RLW Ed,q,χ problem is infeasible. For
this application, the security parameter λ is on the order of |λ| =
102, s is the secret key, ei is generated noise, and χ is assumed to
be Gaussian.
 The operations defined by the BGV scheme are as
follows:

• 1) Encryption: The actual encryption function is fairly straight forward given that the
complexity is built into the mathematical structure. Given a message m ∈ R2, let m =
(m, 0, 0,..., 0) ∈ RN 2 , where N = (2n + 1)(log(q)), for an odd modulus, q. Then the
output ciphertext is given as c = m + AT · r ∈ Rn1 q , where A is the matrix of public
keys and r is a vector of noise from χN 2 . In plain English, the plaintext message is
added to the secret key with additional noise
• 2) Decryption: The decryption algorithm is even simpler for those who hold the
decryption key. Given a ciphertext c and the secret key s, compute m = (c, s mod q)
mod 2, where c, s mod q is the noise associated with s.
• 3) Arithmetic Operations: This scheme supports a number of operations including
element-wise multiplication and addition, scalar arithmetic, and automorphic rotations
that support efficient polynomial arithmetic (think shift-register encoding). An
automorphism is any mapping that sends every element in a given set to another
element in the same set, that is, φ : A → A by φ(a) = b for a, b, ∈ A and it may be the
case that a = b. Note that these operations take plaintext as their input and produce
ciphertext as their output. While the results of these operations are accurate, the
computation overhead is very high. This project is aimed at reducing this computation
cost to make homomorphic encryption feasible for widespread use
 HElib

•HElib Platform Layers:

•Math Layer:
•Uses the NTL math library.
•Provides mathematical structures and operations.
•Key modules:
•PAlgebra: Defines structures in Z∗Z^*Z∗.
•NumbTh: Offers miscellaneous utilities.
•Timing: Facilitates timing management.
•Bluestein: Supports Fast Fourier Transforms (FFT).
•CModulus: Handles modular arithmetic.
•PAlgebraMod: Manages component-wise arithmetic.
•IndexSet/IndexMap: Provides indexing utilities.
•Double-CRT Representation: Optimizes arithmetic on large polynomials using component-wise operations
 HElib

•.
•Cryptography Layer:
•Contains modules for key-switching, encryption, decryption, and ciphertext operations.
•Key modules:
•KeySwitching: Manages matrices needed for key switching.
•FHE: Manages cryptographic operations (e.g., Key Generation, Encryption, Decryption).
•Ctxt: Manages all operations on ciphertexts.
•EncryptedArray: Routes plaintext slots for operations.
•FHEContext: Maintains parameters across operations.
 HElib
•HElib Parameters:
•k: Security parameter, default value of 80 (minimum for security).
•m, p, r: Defines native plaintext space Z[X]/(Φm(X),pr)Z[X]/(\Phi_m(X), p^r)Z[X]/(Φm​(X),pr),
where mmm aligns with the security parameter.
•d: Degree of field extension (default is 1 for linear factors).
•R: Number of rounds (default is 1).
•c: Columns in key-switching matrices (default is 2).
•L: Levels in modulus chain (default is heuristic).
•s: Minimum plaintext slots (default is 0).
 ACCELERATING HOMOMORPHIC
ENCRYPTION
• Evolution of GPUs:
• GPUs evolved from simple display applications in the 1980s to complex computations
like 3D rendering.
• In 2007, NVIDIA’s CUDA enabled widespread use of General-Purpose GPU computing
(GPGPU), managing multiple cores efficiently.
• Advantages of GPUs for HElib:GPUs act as mobile high-performance computing (HPC)
devices, suitable for applications needing real-time data processing (e.g., on
UAVs).Reprogrammable GPUs fit military and mobile applications by providing real-
time feedback.
• Profiling and Identifying Intensive Tasks in HElib:Key HElib functions (encoding,
encryption, arithmetic operations) were profiled to identify computational
bottlenecks.
• Time-consuming, repetitive algorithms were targeted for GPU-based parallelization.
• CUDA Overhead:CUDA overhead includes memory allocation, transfers (host-to-
device and device-to-host), and deallocation.
• GPU initialization incurs a one-time cost that must be factored in when porting code.
 ACCELERATING HOMOMORPHIC
ENCRYPTION
•Parallelization Strategy:
•Following Amdahl’s Law, code sections with the most potential for parallelization were
identified.
•BluesteinInit() and BluesteinFFT() functions were found to be the most
computationally intensive in HElib, taking up about 10% and 46% of execution time,
respectively.
•Implementation of Parallelization:
•Bluestein FFT code was partially ported to the GPU using CUDA for significant
speedup, leveraging GPU capabilities to reduce processing time for key operations in
HElib.
 CallForF ire

• Overview of CallForFire Application:

• A mission-critical application built using the Nomad framework.
• Supports "Call for Indirect Fire" strategy to target enemy positions.
• Involves four main roles:Forward Observer (FO): Identifies and
locates targets, requests fire, and reports results.
• Fire Direction Center (FDC): Analyzes data, authorizes fire missions,
and directs fire units.
• Firing Unit (FU): Executes the fire mission.
 CallForF ire
• Key Concepts:
• Observer Target Line (OTL): Direct line from FO to HVT.
• Observer-Target Direction (OTdirection): Angle between FO and HVT.
• Observer-Target Distance (OTdistance): Distance between FO and HVT.
• Role of Forward Observers (FOs):FO scouts areas and gathers
sensitive intelligence.
• Information collected must remain secure to protect mission success
and personnel safety.
• FO Methods for Determining HVT Location:
• Polar Plot: Describes target location relative to the FO (used in
CallForFire).
• Grid Coordinates: Provides exact grid location of the HVT.
• Shift from Known Point: Describes the target's position relative to a
known point.
 CLocation Calculation using Polar
Plot:
• Utilizes the Military Grid Reference System (MGRS), dividing the
world into 100,000-meter grids.
• MGRS coordinates consist of:
• Grid Zone Designator (GZD): Identifies vertical grid zones.
• Square Identifier (SQID): Specifies a 100,000-meter square within the
GZD.
• Easting and Northing: Precise location coordinates within the square.
• Given FO's position and target’s direction and distance, HVT
coordinates are calculated:
• HVTeasting=FOeasting+OTdistance×sin⁡(𝜃)
• HVT easting​=FO easting​
+OTdistance×sin(θ)HVTnorthing=FOnorthing+OTdistance×cos⁡(𝜃)
• HVT northing​=FO northing​+OTdistance×cos(θ)
 CLocation Calculation using Polar
Plot:
• Converting Coordinates for GIS Mapping:
• MGRS coordinates converted to Universal Transverse Mercator (UTM)
for GIS map plotting.
• Conversion includes GZD, hemisphere, easting, northing, and precision.
•Example Scenario:
•Recon team identifies a weapons cache 100 km NE from base.
•FO position: MGRS coordinates 11S NU 80305 10323.
•HVT located 812 m from FO at a 1239 mil azimuth.
•Calculations:
•HVTeasting=803050000+812×9379=810665748\text{HVT}_{\text{easting}} = 803050000
+ 812 \times 9379 = 810665748HVTeasting​=803050000+812×9379=810665748
•HVTnorthing=103230000+812×3470=106047640\text{HVT}_{\text{northing}} =
103230000 + 812 \times 3470 = 106047640HVTnorthing​
=103230000+812×3470=106047640
•Results sent encrypted to FDC and decrypted to obtain coordinates: 11S NU 81066 10604.
 CLocation Calculation using Polar
Plot:
Data Handling with Homomorphic Encryption:
•Target information is encrypted before transmission to the cloud.
•Homomorphic encryption enables secure computations on encrypted data.
•Pre-computed sine and cosine values scaled to integers (using a scaling factor)
allow efficient calculations, avoiding costly bootstrapping operations.
 CallForFire performance

•Computation Overhead:
•Measures time required for encryption, location computation, and decryption.
•Key findings:
•Encryption of location data (six parameters): ~0.64 seconds.
•Computation of target’s east and north coordinates (easting and northing): ~2.2 and
~2.34 seconds, respectively.
•Decryption of location data: ~39.2 seconds, which is higher due to the lack of efficient
data packing.
•Transmission Overhead:
•Evaluates end-to-end time for transmitting encrypted vs. unencrypted data.
•Key findings:
•Transmission of unencrypted FO location to FDC: ~1.1 seconds.
•Transmission of encrypted FO location to FDC: ~23.5 seconds.
•The increased time reflects the additional overhead of encryption but still supports
feasible communication.
•Storage Overhead:
•Assesses storage requirements for encrypted vs. unencrypted data.
•Key findings:
•Each encrypted location requires significantly more storage than the unencrypted
version, due to the larger ciphertext size.
•Example: average size of an encrypted location is around 8.96 MB compared to 17.6
bytes for unencrypted data.
•Compression methods help reduce storage but remain a key area for optimization.
•Overall Feasibility:
•Despite higher computational and storage costs, CallForFire demonstrates that secure
cloud-based operations are achievable.
•GPU-based parallelization and homomorphic encryption allow real-time processing for
defense applications, balancing security and performance.
Thank you