THE PEER-REVIEWED VERSION IS AVAILABLE AT IEEEXPLORE.IEEE.ORG
1
SIMS: A Comprehensive Approach for a Secure Instant Messaging Sifter G¨unter Fahrnberger University of Hagen, North Rhine-Westphalia, Germany Email:
[email protected]
Abstract—Instant messaging (IM) stands for a visual mode of communication with the chance of realtime responses but without (needed or wished) face-to-face contacts. In particular, youngsters prefer instant messengers to kill time if they are bored and nothing else within range interests them. Harmfully, they may get in touch with inappropriate language there. Much worse, their habitation in such virtual venues allures child molesters as well. Even chatting majors may be sighted and hassled to obtain exploitable private data from them. This paper aids by evaluating a comprehensive threat model for censored IM traffic in order to draft a security policy for IM clients, transmission facilities, and IM platforms with a bulk of desired protection properties. Finally, an innovative IM architecture kit becomes conceptually introduced that meets all advised requirements and, therefore, mitigates the threats. It contains a secure IM filter that guarantees not only authenticity, integrity, privacy, and resilience but also prevention of abusive language, cyberbullying, molestation, and others exploits. Index Terms—Authenticity, Blind Computing, Censorship, Cloud Computing, Filter, Instant Messaging, Instant Messenger, Integrity, Privacy, Protection, Resilience, Security
I. I NTRODUCTION Communication has always accompanied group-living beings as their tool to consign warnings of threats, signs of water or nutrition (yet edible or intended for hunting) and pairing advances. Beyond that, higher developed creatures (like humans) also communicate to pass down knowledge and to entertain themselves mutually. Beside impersonal, undirected and non-interactive entertainment (like television or theater), folks gratify their sensation mongering by exchanging past or imminent blatant happenings in their environment by a variety of messages. Phonemes started out as the first message bearer, complemented through pictographs. The evolution and bidirectional translation abilities of literary languages steadily endorsed the communication of scattered tribes more and more. Letters set out as the precursor of written messages. The emergence of electrical signal transmission amplified letters to telegrams and personal conversations to telephone and video calls. The digital age let arise dedicated protocols for the transfer of instant messages between chatters. Nowadays, we experience the convergence of acoustic and visual contents through all-round multimedia-facilitating Internet-protocols that convey them within common transmission channels and paths between two or more parties. Originally, users joined virtual chat rooms with adjustable anonymous nicknames instead of concrete authentication credentials. Until today, instant messengers have ousted classic chats, fostered dialogs rather than multiple-user conversations and respected present-
day safety requirements by extorting fitting login data from the registered users in order to provide them communication with their (confirmed) virtual contacts. Howbeit chats and instant messengers as well as techniques to filter them coalesce more and more, this treatise zooms in on IM systems with sieving abilities. All IM mediums suffer of two chief classes of vulnerabilities if appropriate countermeasures have been neglected or even desisted. The first of them matters to the IT (Information Technology) security goals authenticity, integrity, privacy and resilience. How do examples for violations of these targets for voice and text broadcasts look like? A covertly impersonating speaker or writer harms the authenticity. A dork or killjoy who adds, modifies or suppresses information during Chinese whispers offends the integrity, just as deliberately carving out voice sequences of a phone call in a switchgear or manipulating instant messages in a proxy. Wiretaps intentionally destroy the privacy. Eventually, overwhelming a communication service with a DoS (Denial of Service) attack through a single entity or even a DDos (Distributed Denial of Service) attack through a herded bot-net firmly defeats its resilience. Historically, about 90% of computer security research delved into privacy and integrity problems, about 9% dealt with authenticity issues, and approximately 1% only addressed shortcomings in resilience [3]. Actual strikes and companies’ defense expenses tend to be the other way round: more funds flow into the retention of resilience than into the other three security aims altogether [3]. The second kind of vulnerabilities concerns the wrapped contents of messages. Boorish or even vicious talkers or chatters fabricate undesirable dubious utterances. Manifold factors cause the generation of annoying expressions. Not only but especially children are swamped with harassing sentences due to their little experience of life. Least severe but already remarkable may be imprudent oral or written online dialogs with the neighbor kid that drops some unseemly cusses. The underage listener or reader adopts swearwords either subliminally or consciously. The problem aggravates and drifts to bullying if conversations entail insult at the recipient’s end rather than changing his habitual language use. Cyberbullying has evolved as buzzword for affronts induced through online media. Fatal cases of cyberbullying (particularly against teenagers) with suicide of the aggrieved party emphasize not to underestimate this type of oppression. Further exacerbation incurs if ostensible smalltalk just aims at criminal objectives. Felons intend to win the victim’s confidence in order to
THE PEER-REVIEWED VERSION IS AVAILABLE AT IEEEXPLORE.IEEE.ORG
exploit him sexually or monetarily. Usually, they start with the broadsword and create huge masses of contact requests, mainly in written form via junk mails or friendship requests in social media. Responders are treated with the scalpel, which means that they become entangled in intensive seesaws until the villain succeeds or (unfortunately rarer) gets seized. This publication contributes with an approach named SIMS (Secure Instant Messaging Sifter) as a panacea to make online IM platforms bulletproof against both recently mentioned sorts of weaknesses. It censors traversing messages that comprise disputable and wicked words (fetched from an online repository) in IM channels on demand of the receiving participant or his legal guardian. Censoring means the eradication either of the shady words or of whole contaminated messages. Additionally, SIMS abides the security necessities authenticity, integrity, privacy, and resilience for all subscribers of the IM platform. The maintenance of authenticity assures the chatters of communicating with the pretended partners. The warrant of integrity ensures either unaltered information or revised through SIMS only. The promise of privacy conceals message contents against eavesdropping. The guarantee of resilience avoids service outages even in case of vast malicious glitches. Elaborations of completely novel concepts typically favor topdown-oriented approaches, like the waterfall model sparked off by Winston Royce [33]. Upgrades and retrofits of existing designs prefer prototyping amended with iterative development steps, e.g. the spiral model invented by Barry Boehm [5], [6]. Independently of the chosen software engineering model, the responsible solution architect ordinarily must cope the stages threat model, security policy and security mechanism [3]. In simple terms, they can be expressed as What are the threats?, Which methods can be applied against the threats? and How do these methods work? Accordingly, this publication is organized as follows: Section II models all involved parties in an IM scenario respectively the threats they originate. Section III points out the inferred sifter criteria and properties to be encompassed during the engineering process. Section IV characterizes similar assignments, their appropriate approaches and what lacks in them to resolve the scope of this publication. The deduced architecture details are to be found in section V. Ultimately, section VI summarizes the merits of the proposed solution and fades out with future work.
2
Fig. 1. XMPP Architecture [10], [27]
The dangerousness diversifies from evildoer to evildoer. By way of example, the paper about the design of the IBM 4753 high-end cryptoprocessor classifies them into clever outsiders, knowledgeable insiders, and funded organizations [1]. The construction of a decent architecture insists on thinking not only like a respectable chatter to produce sophisticated features but also as a crook and their opportunistic evil raids that must be unconditionally circumvented. The threat model in this section bears neutral actors in mind as subjects who excel themselves by behaving benign but accounting nothing against malign offenses. Thus, neutral players lend themselves to be easy targets for cankered assaults. After all, there is nothing else for it but to adamantly defend the friendly accessories against the uncommitted ones, just as against allegedly iniquitous fellows. Figure 1 briefly depicts an XMPP (eXtensible Messaging and Presence Protocol) [34]–[38] architecture supposed to represent all IM protocols. It allows the distinction of the following six apparent groups of natures: IM Client Users, IM Client Attackers, Transmission Providers, Transmission Attackers, IM Platform Providers, and IM Platform Attackers. Being an offender implies the straightforwardly vilification as antagonist, but the unambiguous classification of the remaining roles into protagonists, antagonists, or neutralists fails, because the members of a group either act hybrid or alter their attitudes and behaviors in fact. Whatsoever, the characteristics of all six enumerated categories follow. A. IM Client Users
II. T HREAT M ODEL This section scrutinizes the latent and evident safety hazards for IM traffic and distills the outcomes into a threat model. The structured threats equate the challenges that must be tackled inside this document. The identification of all acting protagonists, antagonists, and neutralists plus their assumed action patterns keenly gears to applied game theory and situation assessment in military organizations. The protagonists allegorize the good guys who either innocuously utilize an online IM platform or operate equipment to enable the IM service collaboratively. The antagonists proceed autonomously rather than collectively to take advantage of raising endangerments against social networks.
The chatters who bandy their messages through an IM platform constitute the sole purpose for its existence. If they hold off after the introduction of a new or during the operation of a running IM platform, then few to no reasons stay to spend money for keeping it online. The majority of the client users duly handles the offered communication opportunities and hence belongs to the wanted profile of friendly facilitators. Not quite correct! A remarkable percentage of proper chatters behaves nicely but throws all common sense overboard by cultivating really bad habits regarding the handling of their own confidential data. If they access an instant messenger via unsecured channels despite safe ones are available in parallel, it may be still pardonable due to deficient recommendation
THE PEER-REVIEWED VERSION IS AVAILABLE AT IEEEXPLORE.IEEE.ORG
3
for reliable alternatives, and the running of insecure access facilities by the accountable service provider. Another explanatory model may be missing sustainable sensitization of the average citizen with regard to implications of data theft and abuse. However, end-users who frivolously expose their private credentials (peculiarly their passwords) by choosing them guessable for third parties, by scrawling them on sticky notes, or even by voluntarily imparting them to other persons deserve to be degraded to neutralists; the best safety system cannot outweigh such conduct. Even worse, participants who flout or impersonate others definitely affiliate with the family of adversaries. Far the worst, chatters unexceptionally qualify as miscreants who hardly attempt to undermine the filter functions. These may be minors tired of being patronized who try to elude to IM clients without censorship (if locally supervised) or uncensored IM services (if centrally monitored). Adults who spend efforts to bypass a content sifter can sorely impute fraudulent, deceiving, sexual, or miscellaneous criminal intents (mostly against naive peers such as kids).
D. Transmission Attackers
B. IM Client Attackers
E. IM Platform Providers
The first ilk of assailants pursues the goal to compromise mobile and fixed terminals with the installed IM client application (e.g. smart phones, tablet computers, laptops, or workstations) to spy out, modify, or disrupt sensitive data on the one hand, or to disguise the own identity and benefit from the victimized computers as roots for offensives against more crucial primary targets on the other hand. The predators may profit from stolen passwords (for example through keystroke or screenshot recording) that work also for the prey’s other accounts or from revealed location information gathered in afflicted GPS (Global Positioning System) or A-GPS (Assisted Global Positioning System) modules by selling or exploiting it to loot empty premises. The pool of penetration possibilities incorporates all ways of malware (i.e. viruses, worms, and Trojans) that covertly infiltrate the targeted machines in order to acquire control over the devices.
While BBSs (Bulletin Board Systems) accessible through dial-up connections were allaying the lust for interpersonal interaction between a couple of technology freaks in the old days, large globally omnipresent firms have let spring up IM platforms like mushrooms with millions of international ordinary subscribers. Formerly pure IM projects, e.g. ICQ (I seek you), have abated and made room for multimediaenriched social networks (like Facebook, Twitter or Google+) where members satisfy their friends by sharing nearly every minute of their lives. Nevertheless, the mere instant messenger WhatsApp has proved the opposite with its prosperity up to now. The avowedly fuzzy border between respectable and neutral IM platform providers should be similarly drawn to that one of transmission providers, i.e. depends on the sufficiency of their expenditures in security precautions. Corporations proffer IM services to harvest advertising revenues or reputation at least rather than to charitably sponsor maintenance fees for the necessary IM infrastructure and its administration personnel. As a result, almost all IM vendors integrate adware in their supplied client software or place advertisement banners on their websites to generate income. As long as chatters do not perceive the ads as aggressive, there persists yet no reasons to complain about. However, once the ads become onerous or the suppliers in charge collect and commercialize private data illegally, their business practices begin to be noticed as dubious.
C. Transmission Providers The term Transmission Providers incloses all facilities and networks, for instance ISPs (Internet Service Providers) and backbone operators, which abet the traction of interchanged messages between IM clients and platforms. The ones that proactively consider all historically and topically imaginable security risks against themselves by running the most safeguarded, disposable hard- and software decidedly have to be respected as white-list cooperators. Correspondingly, those that steadfastly ignore or even negate any prophylactic measures or responsive countermeasures have to accept being neutralists. Much the worse are transmission enterprises that stick at nothing to maximize their earnings. Subsequently, they unopposedly conspire with intelligences or equivocal business partners by admitting wiretaps respectively through the handover of traffic log data. Such economically oriented companies inevitably appertain to foes.
The second kind of assaulters focuses on grabbing, varying, or denying valuable data by means of transmission paths. Compared to client attackers, they resort to packet sniffers rather than to malware. The unimpeded propagation of freely available packet analyzers combined with absent transport encryption of communication lines permits even low-skilled wretches equipped with access to transmission elements direct glimpses of transferred information. Well-versed hackers conduct more brute intrusions with man-in-the-middle-attacks into data streams to rip authentication flaws in link protocols off. In other words, they initially crack poorly secured IM sessions, study the spelling style of the online mates of envisaged victims and replace desired messages towards the victims with feigned ones in order to elicit confidential knowledge (such as their watchwords or their credit card details) or personal information (like nude pictures of them). It goes without saying that the latter in the wrong hands let prosper blackmails with eventual ransom demands.
F. IM Platform Attackers These delinquents become united by their will to break individual IM accounts at least, to destabilize the service availability or to intrude into the IM platform in order to interrogate, change, or delete data there. Phishing (Password harvesting fishing) denotes a modern fraud in which faked IM entrance portals tempt innocent chatters to input their login credentials there in order to be used for further deception. In
THE PEER-REVIEWED VERSION IS AVAILABLE AT IEEEXPLORE.IEEE.ORG
such a scenario the fraudsters do not even need to agonize how to trespass upon the real IM platform. Anyway, big web service offerers continuously improve their knowhow about security to shield their products against external invaders, but they often underrate or disregard the intrinsic threat of safeguard violations through reputedly trusted staff [11]. Dhillon estimates that internal intruders carry out between 61 and 81% of computer related crimes [11]. This high percentage does not need to astonish because most of the mounted defensive measures (such as firewalls, reverse proxies, or physical access controls) flop in case of insidious employees who evade them. The danger worsens if a company hires cloud resources to run its instant messenger. Then the risk group of potential inhouse crackers covers both the workers of the IM operator and of the cloud provider. Purloining directly usable money lures more than stealing data, which has let the financial industry stand out as pioneer and idol of discovering capabilities against deceitful insiders. III. S ECURITY P OLICY The introducing section I assigned the mission of this contribution. Section II assessed the status by sorting the recognizable influencing factors of instant messengers into enemies, friends, and neutralists and illuminating their different intentions. Derived from both previous sections, the current one dedicates itself to the determination of the security policy. Anderson specifies a security policy as a succinct statement of the protection properties that a system (or generic type of system) must have [3]. Ferguson and Schneier state the comparable term Functional specification in their nomenclature [19]. Both definitions amalgamated, the security policy appears as a set of functional requirements for the focused hardened filtering IM system that must be measurable without knowing implementation details. Distinguishing the requisites into subsets (each of them mapped to one of the three architectural components of an IM application) leads to clear security policies for IM clients, transmission networks, and IM platforms. Although, existing generic items valid for the complete IM architecture become hereinafter alluded. Every security system is subject to the weakest link property and, thus, likely becomes challenged at its softest spot [19]. Hence, the proposed filter solution makes only sense if it exclusively consists of sorely approved-as-secure hardware devices and operating systems. One must not forget that all people in touch with the IM platform (eminently the chatters) may be these weak points as well, for example, if thugs lure them to make all protective technical appliances useless by disclosing their secrets. Sharpening of the users’ security awareness through education (favored during primary school already) about electronic safety affairs seems to be the optimal remedial prophylaxis. Transient secrets (e.g. temporary session keys) must be wiped in all memories as soon as they are not going to be queried anymore and, thence, have become needless [19]. Complexity denotes to be the most horrible opponent of security. Consequently, a complex safety system must be simplified from the ground up by keeping the number of configurable
4
options as low as possible and building it up in reasonable encapsulated modules with clear and simple interfaces between them [19]. Simplification by having minimal settings and modularization yields better overview, quicker debugging, and faster replacement of units whose vulnerability exceeds any observable modern security norms [15]. Real Random Number Generators (RRNGs), if available, or Pseudo Random Number Generators (PRNGs) seeded with real random data at least, must be the only entitled objects that may output randomized data for the IM system, such as nonces, salts, and volatile session keys [19]. Last but not least, realizers of SIMS (and every other cryptographic protocol or system) are urged to circumspect code development, because implementation-related holes creep more easily in program codes than in design concepts [19]. A. IM Client Security Policy Regardless of the IM client application type (web browsers or special applications for tablet computers and smart phones), all of them must be the sole constituents of an IM architecture that may legally prompt chatters to enter (plaintext) instant messages, may display and buffer them. For this reason, the human users, their terminals, and the installed IM client applications together with their associated operating procedures make up the Trusted Computing Base (TCB). Formally, the TCB comprises of the set of components whose correct functioning suffices to ensure the enforcement of the entire security policy, or, more vividly, whose failure could cause a breach of the security policy [3]. Almost all safety precautions in client software can be more easily defeated with physical access to the underlying hardware. This calls for the installation of terminal protection, among other things by an automatic lock of input and output peripherals (such as keypads and display screens) after a configured idle time period, which may be only released with the credentials of authorized users. These days, clients with operating systems based on Windows count on malware scanners as installed default software. Android, iOS, and Linux devices are mostly objected to be shipped without such supplementary utilities. It is strongly advisable for owners working with Linux derivatives to close this kind of loophole due to contemporary malware. The malware scanners must automatically impede outdated local repositories by periodically updating themselves. Even IM clients infected with pernicious software must deter sensitive data from leaving them unintentionally by means of locally deployed firewalls that block any sessions initialized from outside and let only pass protocol data units (PDUs) of harmless applications. If the surroundings of the IM client application – the user terminal and the rolled out operating system jointly – suit the expectations of the recent paragraphs, then the discussion may continue with the constraints of how to add a new client account. The following highlighted quintuple uniquely determines each account. An RNG of the IM platform arbitrarily engenders an initial password and a unique (humanly readable) login name, both unguessable for foreign parties. The user
THE PEER-REVIEWED VERSION IS AVAILABLE AT IEEEXPLORE.IEEE.ORG
keys in two further identifiers of himself: a nickname shown to his verified contacts only (that may out his real name) and a publicly visible pseudonym. His e-mail address as the last asked text field becomes fundamental to gain a new temporary (randomly rendered) password in an e-mail if he signs up or feels compelled to recover his account. All entries of a quintuple must pair-wisely differ, only the nickname and the pseudonym may match. Passwords underlie further restrictions: automatically alloted ones must be exchanged for user-specific ones on successful logins, and an entrenched crafty password policy must coerce complex watchwords. Generally, genuine account creations crave for two extra barriers: CAPTCHAs (Completely Automated Public Turing tests to tell Computers and Humans Apart) to ward off automatic (mass) creations and confirmation links via e-mail to hinder anonymous creations. Both hindrances cannot prevent rogues from operating under several identities (Sybil attacks [13]). To accomplish the enrollment process, the IM platform forces the client application to generate a key pair of a defined topical public-key cryptosystem and to register the public key in the certification authority (CA) of a trusted third party Public Key Infrastructure (PKI) in order to download the corresponding CA-signed client certificate that is going to be publicly dispensed for identification and session key negotiation. B. Transmission Security Policy The preceding subsection about IM client security policy tagged physical protection as prerequisite for broader safety measures. Transmission routers and hops may carry the data packets of many chatters among the voluminous Internet traffic that they have to manage. Intercepted uncovered source or target IP (Internet Protocol) addresses in occurring datagrams may draw precious conclusions about traffic relations, geographical positions, and so on. Due to worse consequences because of significantly more possibly affected victims, limiting local ingress into transmission sites as well as restricting remote (administration) gates to communication equipment to the least unavoidable amount possesses more critical importance than deflecting menaces to individual terminal devices. Compulsory lawful contracts (e.g. nondisclosure agreements) must interlace with technical gadgets to do justice to the indispensable access restraints. Transmission in informatics means, as the name says, the carriage of data from sources to destinations with various protocols, but without changes of their meaning. Therefore, the information in the PDUs can be unproblematically transmitted in a scrambled manner. Due to this fact, each IM client application employs transport encryption by establishing a virtual tunnel to the IM platform with a state-of-the-art hybrid cryptosystem as long there subsist live sessions that need to be channeled through. The public key based part of the hybrid cryptosystem presumes that the client device has its certificate (which should have been created as announced in the previous subsection about IM client security policy) available to identify itself towards the IM server and to agree on terminable session keys. Furthermore, the client expects to
5
receive a server certificate in order to validate it with the help of a trusted third party CA. C. IM Platform Security Policy The IM platform shall store and forward messages to the destined addressees without becoming aware of their contents. End-to-end (E2E) cipher would be convenient for this purpose, but the filter function necessitates trickier mechanisms. Techniques exist to ascertain ciphertext that encircles explicit unwanted character strings and phrases, but they can only remove the whole concerned instant messages. The approach SafeChat [18] even overcame this constriction by adopting the deterministic homomorphic cryptosystem SecureString 2.0 [16], but apart from suboptimal performance, it only concentrated on achieving data privacy, while authenticity, integrity, and resilience were not guaranteed. Lacking authenticity puts SafeChat in jeopardy of man-in-themiddle attacks. SIMS remedies this deficit with an already broached feature – a valid host certificate suitable for identification and for session key stipulation that must be put into operation exactly like a client certificate before the service goes online the first time: key pair production, public key registration in a trusted third party CA, and server certificate download in order to make it available for inquiring clients. The use of Electronic Codebook Mode (ECB) in SafeChat alleviates the search for equal characters within the same word, but facilitates cut and splice attacks [3] (especially by insiders of the IM provider) and, thence, puts integrity at risk. Admittedly, integrity deserves more attention than privacy because viciously modified text harms more than illicitly read one. The obligatory refinement of the implanted homomorphic cryptosystem in SIMS through prudent employment of Message Authentication Codes (MACs) restores and preserves integrity. The MAC must thereby be protected together with the related instant message through a conjoint cryptosystem [19]. Moreover, the encipherment of a MAC (that endorses the integrity of plaintext rather than that of ciphertext) together with the related plaintext complies to the Horton principle Authenticate what is being meant, not what is being said! [19]. SafeChat omitted to discuss the vital impact of physical access conditions on resilience. Contrarily, the preceding subsection about transmission security policy indicated how important access protection for sites with communication facilities is. The quality of access controls to computing centers, which contain (copies of) the IM platform, needs to be higher because even the breakdown of one mirror degrades the redundancy of the IM service, let alone the crash of all replicas that brings a full service outage in its wake. Albeit an IM service that runs in a cloud or in a comparable virtual hosting solution affords greater resilience, the demands on access limitations for the appropriate data processing centers stay the same. SafeChat arranged all client terminals to retrieve unpleasant character strings and their synonyms from a well-maintained online database (e.g. WordNet [26] for the English language) to encrypt each of them for each typed word with SecureString 2.0 combinatorially and to pass the resulting filter
THE PEER-REVIEWED VERSION IS AVAILABLE AT IEEEXPLORE.IEEE.ORG
repository to the IM platform in order to trigger remote sifting of each dispatched instant message. Executed for millions of simultaneous users, this would exhaust the capacities of the IM core and the transmission infrastructure in a blink. SIMS skirts these infeasible outlays through a two-tiered sifter process as follows. During the first stage, the consigner device dictates the (symmetric) session key and makes its communication partner and a Trusted Third Party Generator (TTPG) securely aware of it by enciphering it with the public key of the receiver’s certificate, respectively with the public key of the certificate of the TTPG. Unlike the TTPG, the IM partner receives its ciphertext key attached to the first incurring message of the conversation. In reference to the gained session key, the TTPG compiles a template embodying all undesired keywords by dint of a parametrized trapdoor function to an enciphered errortolerant bloom filter repository (that is applicable for the ongoing session) for an efficient searchable symmetric encryption (SSE) scheme in order to hand it over to the filter process located in the IM platform through a dedicated secure highspeed Wide Area Network (WAN) [39]. The utilized template depends on the consignee’s online configuration settings that refer to a plaintext bad word dictionary. The two clients apply their shared secret key to exchange their session data with the aid of the SSE that gives the sifter the possibility to detect objectionable content without recognizing the meaning. Thence, the IM platform interconnects the complete dialog without standing a chance of a prosperous attack. While an inoffensive message may pursue the way to its destination, another one with enclosed ominous ingredients must be more accurately examined in the second stage. The filter component executes the second stage even for diagnosed maleficent messages that shall be entirely eradicated because the first step encounters non-zero probability of falsely recognizing unrelated words [8], [40], i.e. there exist slight odds of suspected messages that are unperilous in truth. The second stage begins with the IM platform commissioning the sender terminal to encipher an arbitrary initial salt with the public key of the certificate of the TTPG. After obtaining the salt, the TTPG takes over the fabrication of the filter repositories with SecureString 2.0 in consideration of the selected template and session key of the first stage as well as their delivery to the permanently tied IM service through the secure high-speed WAN. Once the TTPG has fitted the sifter with a capable repository, the sender device also applies SecureString 2.0 to reencrypt the message with the questionable text in order to shift it to the IM platform for verification. According to the addressee’s online configuration settings (as explicated for SafeChat in detail [18]), the filter component either blindly clears out the malfeasant fragments and forwards the remainder to the receiver or even drops the full message. The ciphertext message must comprehend all its words en bloc to hide their boundaries and thus to hamper repetition pattern attacks [17] – a subtype of the dictionary attacks. In addition, the salt must switch after each character string delimiter (e.g. blank) to diminish ciphertext repetitions and, hence, to complicate character distribution attacks [17]. It suffices to transmit the first salt from the client to the TTPG
6
because both can attain the subsequent ones through automatic salt updating [3], which means that each salt serves as input of a one-way hash function that spawns the successive salt. On the one hand, key updating minimizes salt transfers. On the other hand, backward security holds because no salt can be concluded from its successors. Even though the TTPG can compute all salts and lets sprout all repositories with sought deprecated terms, it cannot observe any IM traffic and found hits because only the screening IM platform gets in touch with messages. Disadvantageously, this way of secret sharing disallows autokeying [3], which means that two or more principals with a common key hash (plaintext) messages that they have exchanged to synthesize new salts. Autokeying would perpetuate forward security, which means that no salt sheds light on its successional ones [3]. If the recipient is offline, then the filter checks the message thread as previously described. Afterwards, the IM platform deposits the cleaned messages (encrypted with the cryptosystem of the last performed stage) inclusive the adhered ciphertext session key in its storage till it can deliver them. IV. R ELATED W ORK An explicit security policy for a censoring IM service on the basis of blind computing (as prepared in the previous section III) is new and proves the right of this paper to exist. Nonetheless, ideas in related work have already solved subproblems that were addressed in the security policy. Appreciatedly, these ideas can be recycled fully or at least partly within the next section V about security mechanism. A. Instant and Chat Message Filters The first remarkable sort of relevant literature chiefly bothers with architectural questions about instant and chat message filters, i.e. how to compose them technically. Chung surveyed some of the technical solutions available to parents to protect their children from the dangers of the Internet and suggested SecureNet as a product that binds filtering and monitoring [9]. Boss and McConnell contrived a contextual filtering system that allows its users to define one or more topic- or timebased contexts that describe the type of instant messages which they are willing to receive [7]. Landsman’s IM filter discourages human and machinable spIMers (IM spammers) to flood innocents with unsolicited content through a mandatory verification process for each sender plus white- and blacklist options [24]. MacFarlane and Holmes educed an agent mediated autonomous system that automatically blocks the transmission of messages with personal data (such as addresses and telephone numbers) to make it safer for children to chat online [25]. Ganz and Borst bet on their multiple-layer chat filter system that relays a sent message only if it includes just whitelist and no blacklist words [20]. All suggestions above blatantly miss out on supporting the IT security goals authenticity, integrity and privacy and vindicate the invention of SIMS. B. Topic Detection The second class of relevant scientific disquisitions essentially grapples with topic detection of instant and chat
THE PEER-REVIEWED VERSION IS AVAILABLE AT IEEEXPLORE.IEEE.ORG
messages plus the decisions which themes are worth to be blocked. Bengel et al. demonstrated the text classification system ChatTrack which creates a concept-based profile that represents a summary of the topics discussed in a chat room or by an individual participant [4]. Penna et al. researched methods that would aid in the process of automating the detection of pedophile activities on the Internet [31]. Dong et al. investigated the characteristics of chat messages and proposed an indicative term-based categorization approach for chat topic detection [12]. Pendar presented the results of a pilot study on using automatic text categorization techniques in identifying online sexual predators [30]. Ishii et al. considered the three topic extraction methods Pressure Scoring, Unexpectedness Scoring and Partial Matching Scoring for a text-based communication channel of a message stream in bulletin board or chat services [23]. Adams and Martell disclosed preliminary methods of topic detection and topic thread extraction that augment a typical TF-IDF-based vector space model approach with temporal relationship information between posts of the chat dialog combined with WordNet hypernym augmentation [2]. Hui et al. came along with IMAnalysis that supports chat message retrieval, social network analysis and topic analysis by using text mining techniques [21]. Roth explored a system to discover important words in instant messages in order to decide which ones are related to one another [32]. Elzinga et al. brought up a method based on temporal concept analysis using temporal relational semantic systems, conceptual scaling and nested line diagrams to analyze chat conversations concerning grooming (Process by which pedophiles try to find children on the Internet for sex-related purposes.) [14]. Peersman et al. advocated their proposal for detecting online pedophiles in chat rooms that combines the results of predictions on the level of the individual post, the level of the user and the level of the entire conversation [29]. As declared in the aforementioned subsection about instant and chat message filters, the absence of fulfilled IT security aims in all proposals sanctifies the development of SIMS. C. Searchable Encryption Schemes The third kind of relevant research essays deals with keyword searching in ciphertext documents. There have pullulated hundreds of them, some of which [8], [39], [40] were cited during the elucidation of the IM Platform Security Policy in section III. Beyond them, in regard to SIMS, the approximate keyword-based search over encrypted cloud data of Ibrahim et al. deserves the most advertence because this SSE scheme assembles an adequate list of probably contained candidates in the first step of each quest and reverts to a semi honest third party (like the TTPG) to determine the best matching keywords depending on a secure similarity function in the second stage [22]. Bare searchable encryption schemes must be allied with a condign IM filter conception and a fair topic detection technique to achieve an expedient secure filter resolution. D. Secure Instant and Chat Message Filters The fourth type of relevant scholarly pieces examines enhanced instant and chat message filters that embed topic detec-
7
Fig. 2. SIMS Architecture
tion and searchable encryption. As aforementioned during the explanation of the IM Platform Security Policy in section III, SafeChat [18] of Fahrnberger et al. aggregated the context based authentication features of the 4-CBAF model [28] and the message encryption features of SecureString 2.0 [16], [17] to monitor children’s communications and to eradicate explicit words coming into their devices without recognizing their meaning. Scarce assurance of authenticity, integrity and resilience in SafeChat inspired the advent of SIMS. V. S ECURITY M ECHANISM Anderson defines a security mechanism (a.k.a. security target) as a more detailed description of the protection mechanisms that a specific implementation provides, and how they relate to a list of control objectives [3]. Based on the concise demands in the preceding section III, their fulfillment becomes hereunder stipulated as technical realization. Figure 2 illustrates the elaborated SIMS architecture with all its constituents and their linkages. The security mechanism can be divided into separate workflows that happen in these parts. The following subsections assign a proprietary algorithm composed of pseudo code to each of these workflows. Definition 1 holds all abbreviations used within the algorithms. Definition 1: Let CA be the Certification Authority, let Da be a decryption and Ea be an encryption function of an asymmetric cryptosystem, let Dh be a decryption and Eh be an encryption function of a homomorphic cryptosystem, let Ds be a decryption and Es an encryption function of a searchable encryption scheme, let F h be a filter function of a homomorphic cryptosystem, let H be a hash function, let P be the IM core platform, let PRN G be P 0 s random number generator, let Pcert be P 0 s certificate with P 0 s public key Pe , let Pd be P 0 s private key, let Qh be a query function of a homomorphic cryptosystem, let Qs be a query function of a searchable encryption scheme, let R be the IM receiver client, let Rcert be R0 s certificate with R0 s public key Re , let Rd be R0 s private key, let Rnick be R0 s nickname, let S be the IM sender client, let S@ be S 0 s e-mail address, let SRN G be S 0 s random number generator, let Scert be S 0 s certificate with S 0 s public key Se , let Sd be S 0 s private key, let Slogin be S 0 s login name, let Snick be S 0 s nickname, let Spseudo 0 be S 0 s pseudonym, let Spass be S 0 s password, Spass be S 0 s new password and Sexp a boolean password expiry indicator, let T T P Gcert be T T P G0 s certificate with T T P G0 s public
THE PEER-REVIEWED VERSION IS AVAILABLE AT IEEEXPLORE.IEEE.ORG
key T T P Ge , let T T P Gd be T T P G0 s private key, let m be an instant message, let s be a session key between S, R and T T P G, let sRP be a transport key between R and P , let sSP be a transport key between S and P , let Zhs be a filter repository based on a homomorphic encryption scheme and s, let Zss be an error-tolerant bloom filter repository based on a searchable encryption scheme and s, let t be a binary variable that decides to either block or clean an offensive m, → and let − s− SP be transport encryption based on a symmetric cryptosystem and sSP . A. Secret Symmetric Key Exchange Algorithm 1 exemplifies the secure negotiation of a transport key between the IM sender client and the IM core platform. Algorithm 1 exchangeKey Require: Pcert with Pe , Scert with Se , Sd Ensure: approved or rejected 1: S → P : Scert {Sender certificate transfer} 2: P → CA : Scert {Sender certificate transfer} 3: if Scert invalid then {CA rejects sender certificate} 4: CA → P : rejected {CA rejects sender certificate} 5: P → S : rejected {Core rejects sender certificate} 6: return rejected 7: end if 8: CA → P : approved {CA approves sender certificate} 9: P : PRN G creates sSP {Transport key creation} 10: P → S : EaSe (Pcert , sSP ) {Safe transport key transfer} 11: S : Pcert , sSP ← DaSd (EaSe (Pcert , sSP )) {Transport key decryption} 12: S → CA : Pcert {Core certificate transfer} 13: if Pcert invalid then {CA rejects core certificate} 14: CA → S : rejected {CA rejects core certificate} 15: return rejected 16: end if 17: CA → S : approved {CA approves core certificate} 18: return approved
B. IM Account Creation The execution of algorithm 2 signifies the birth of an IM account and, therefrom, only happens once for each IM account.
8
Algorithm 2 createAccount Require: S@ , Snick , Spseudo Ensure: Slogin , Spass 1: S : exchangeKey {see algorithm 1} −−→ 2: S sSP P : S@ , Snick , Spseudo {Safe sender data transfer} 3: P : PRN G creates Spass and human readable Slogin 4: P → S@ : confirmation URL {URL transfer} 5: if S confirms URL then {URL confirmation} 6: P : account creation {Sender account creation} 7: P : Sexp ← 1 {Coercion to change initial password} → 8: P− s− SP S : Slogin {Safe sender login name transfer} 9: P → S@ : Spass {Sender password transfer via e-mail} 10: end if Algorithm 3 createSession 0 Require: Rcert with Re , Rnick , Sexp , Slogin , Spass , (Spass ,) T T P Gcert with T T P Ge , T T P Gd Ensure: ready or rejected 1: S : exchangeKey {see algorithm 1} −−→ 2: S sSP P : Slogin , Spass {Safe sender credentials transfer} 3: if Slogin or Spass invalid then {Core rejects credentials} → 4: P− s− SP S : rejected {Core rejects sender credentials} 5: return rejected 6: end if 7: while Sexp = 1 do {Sender password change needed} → 0 8: P− s− SP S : request for Spass {Safe pw change request} − − → 0 9: S sSP P : Spass {Safe transfer of new password} 0 10: if Spass valid then {Core accepts new password} 11: Sexp ← 0 {Sender password expiry flag reset} 12: end if 13: end while −−→ 14: P sSP S : approved {Core accepts new sender password} − −→ 15: S sSP P : Rnick {Safe receiver nick transfer} − −→ 16: P sSP S : Rcert and T T P Gcert {Safe certs transfer} 17: S : SRN G creates s {Session key creation} −−→ 18: S sSP P : EaRe (s), EaT T P Ge (s) {Safe sender key transfer} 19: P → T T P G : EaT T P Ge (s) {Safe session key transfer} 20: T T P G : s ← DaT T P Gd (EaT T P Ge (s)) {Session key decryption} 21: T T P G : creation of Zss {Filter repository creation} 22: T T P G → P : Zss {Filter repository transfer} −−→ 23: P sSP S : ready 24: return ready
E. Offensive Instant Message C. IM Session Creation Algorithm 3 reflects the code that SIMS nonrecurrently performs during the beginning of each IM session. D. Inoffensive Instant Message Each new instant message that transits the IM core platform through an established IM session triggers the run of the first filter stage (see algorithm 4). Nonhazardous messages only undergo this stage before they reach their final destinations.
If the first filter stage asserts that an instant message embraces suspect content with a probable rate greater than zero, then SIMS enforces a cycle of the second filter stage for this doubtful message. Algorithm 5 irrevocably rules the treatment of the message (lets pass message if unobjectionable, respectively blocks precarious strings or the whole message). VI. C ONCLUSION The on hand disquisition documents the engineering of SIMS by working off the stages threat model, security policy,
THE PEER-REVIEWED VERSION IS AVAILABLE AT IEEEXPLORE.IEEE.ORG
Algorithm 4 executeFirstFilterStage Require: Rd , Scert with Se , Snick , sRP Ensure: offensive, received, or rejected 1: S : createSession {see algorithm 3} 2: while session valid do 3: if new m entered then {New message arrival} → 4: S− s− SP P : Ess (m) {Safe message transfer} 5: if Qs(Zss , Ess (m)) = true then {Offensive message} → 6: P− s− SP S : offensive 7: return offensive 8: end if → 9: P− s− RP R : Snick , Scert , (EaRe (s), )Ess (m) {Safe transfer of sender cert, session key, and message} 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22:
R → CA : Scert {Safe sender certificate transfer} if Scert invalid then {CA rejects sender certificate} CA → R : rejected {CA rejects sender cert} return rejected end if CA → R : approved {CA approves sender cert} R : s ← DaRd (EaRe (s)) {Session key decryption} R : m ← Dss (Ess (m)) {Message decryption} → R− s− RP P : received {Acknowledgment of instant message receipt} → P− s− SP S : received {Acknowledgment of instant message receipt} return received end if end while
9
Algorithm 5 executeSecondFilterStage Require: Rd , Scert with Se , Snick , T T P Gcert with T T P Ge , T T P Gd , sRP , (salt, ) t Ensure: received or rejected 1: if executeFirstFilterStage {see algorithm 4} = offensive then 2: if Ess (m) = first suspect message in current session or Zhs exhausted then {New filter repository needed} → 3: P− s− SP S : request for salt {Safe salt request} 4: S : SRN G creates salt {Salt creation} → 5: S− s− SP P : EaT T P Ge (salt) {Safe salt transfer} 6: P → T T P G : EaT T P Ge (salt) {Safe salt transfer} 7: T T P G : salt ← DaT T P Gd (EaT T P Ge (salt)) {Salt decryption} 8: T T P G : creation of Zhs based on salt {Filter repository creation} 9: T T P G → P : Zhs {Filter repository transfer} 10: else {New filter repository unneeded} 11: S : salt ← H(salt) {Automatic salt creation} 12: end if → 13: P− s− SP S : request for Ehs (m) {Safe message request} 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24:
and security mechanism. SIMS tolerates throughput performance degradation with the reuse of the non-size-preserving homomorphic cryptosystem SecureString 2.0, but secure design philosophy forbids to cut a security corner in the name of efficiency, because there exist too many fast, insecure systems [19]. SafeChat tracked the same principle, but SIMS features three pivotal advancements. Firstly, a TTPG takes the responsibility for the laborious productions and dispersions of the filter repositories containing the terms to be eliminated in IM traffic. Secondly, the sumptuous cryptosystem SecureString 2.0 only becomes operative in the presumably seldom cases as second stage if the more efficient first stage reckons bad words in instant messages and needs verification to let purge just infected messages. Thirdly, SIMS pays heed to sustain not only privacy but also authenticity, integrity, and resilience. This treatise only capitalizes design matters. Future work may immerse itself in performance aspects and improvements of SIMS. Last of all, it must be said that an extensive commercial launch of the introduced SIMS will expectedly depend on supportive laws because IM service providers would lose the opportunity to turn analyzed IM traffic to account.
25: 26: 27: 28: 29: 30: 31: 32: 33:
→ S− s− SP P : Ehs (m) {Safe message transfer} if Qh(Zhs , Ehs (m)) = true then {Offensive message} if t = block then {Offensive message blocking} return rejected end if Ehs (m) ← F h(Zhs , Ehs (m)) {Message cleaning} end if → P− s− : Snick , Scert , (EaRe (s), )Ehs (m) {Safe RP R transfer of sender cert, session key, and message} R → CA : Scert {Safe sender certificate transfer} if Scert invalid then {CA rejects sender certificate} CA → R : rejected {CA rejects sender certificate} return rejected end if CA → R : approved {CA approves sender certificate} R : s ← DaRd (EaRe (s)) {Session key decryption} R : m ← Dhs (Ehs (m)) {Message decryption} → R− s− RP P : received {Message receipt confirmation} − − → P sSP S : received {Message receipt confirmation} return received end if
ACKNOWLEDGMENTS Many thanks to Bettina Baumgartner from the University of Vienna for proofreading this paper! R EFERENCES [1] D. G. Abraham, G. M. Dolan, G. P. Double, and J. V. Stevens, “Transaction security system,” IBM Systems Journal, vol. 30, no. 2, pp. 206–229, mar 1991. [Online]. Available: https://dx.doi.org/10.1147/ sj.302.0206 [2] P. H. Adams and C. H. Martell, “Topic detection and extraction in chat,” in Semantic Computing, 2008 IEEE International Conference on, aug 2008, pp. 581–588. [Online]. Available: https://dx.doi.org/10.1109/ ICSC.2008.61
THE PEER-REVIEWED VERSION IS AVAILABLE AT IEEEXPLORE.IEEE.ORG
[3] R. J. Anderson, Security engineering - a guide to building dependable distributed systems (2. ed.). Wiley, jan 2008. [Online]. Available: https://www.cl.cam.ac.uk/∼rja14/book.html [4] J. Bengel, S. Gauch, E. Mittur, and R. Vijayaraghavan, “Chattrack: Chat room topic detection using classification,” in Intelligence and Security Informatics, ser. Lecture Notes in Computer Science, H. Chen, R. Moore, D. Zeng, and J. Leavitt, Eds. Springer Berlin Heidelberg, jun 2004, vol. 3073, pp. 266–277. [Online]. Available: https://dx.doi.org/10.1007/978-3-540-25952-7 20 [5] B. W. Boehm, “A spiral model of software development and enhancement,” SIGSOFT Softw. Eng. Notes, vol. 11, no. 4, pp. 14–24, aug 1986. [Online]. Available: https://dx.doi.org/10.1145/12944.12948 [6] ——, “A spiral model of software development and enhancement,” Computer, vol. 21, no. 5, pp. 61–72, 1988. [Online]. Available: https://dx.doi.org/10.1109/2.59 [7] G. Boss and K. C. McConnell, “System and method for filtering instant messages by context,” aug 2004, uS Patent App. 10/356,100. [Online]. Available: https://www.google.com/patents/US20040154022 [8] M. C. Chuah and W. Hu, “Privacy-aware bedtree based solution for fuzzy multi-keyword search over encrypted data,” in Distributed Computing Systems Workshops (ICDCSW), 2011 31st International Conference on, jun 2011, pp. 273–281. [Online]. Available: https: //dx.doi.org/10.1109/ICDCSW.2011.11 [9] K. Chung, “Development of an integrated chat monitoring and web filtering parental control for child online supervision,” Department of Computer Science, University of Bath, Other, may 2004. [Online]. Available: http://opus.bath.ac.uk/16853/1/CSBU-2004-13.pdf [10] Z. Cui and Z. Gu, “Threats to IM and security mechanism analysis of XMPP,” 2007. [Online]. Available: http://www.paper.edu.cn/en releasepaper/content/13806 [11] G. Dhillon, “Violation of safeguards by trusted personnel and understanding related information security concerns,” Computers & Security, vol. 20, no. 2, pp. 165–172, 2001. [Online]. Available: https://dx.doi.org/10.1016/S0167-4048(01)00209-7 [12] H. Dong, S. C. Hui, and Y. He, “Structural analysis of chat messages for topic detection,” Online Information Review, vol. 30, no. 5, pp. 496–516, jun 2006. [Online]. Available: https://dx.doi.org/10.1108/ 14684520610706398 [13] J. R. Douceur, “The sybil attack,” in Proceedings of the IPTPS Workshop, Cambridge, MA, USA, 2002. [Online]. Available: http: //www.cs.rice.edu/Conferences/IPTPS02/101.pdf [14] P. Elzinga, K. E. Wolff, and J. Poelmans, “Analyzing chat conversations of pedophiles with temporal relational semantic systems,” in Intelligence and Security Informatics Conference (EISIC), 2012 European, aug 2012, pp. 242–249. [Online]. Available: https: //dx.doi.org/10.1109/EISIC.2012.12 [15] G. Fahrnberger, “Computing on encrypted character strings in clouds,” in Distributed Computing and Internet Technology, ser. Lecture Notes in Computer Science, C. Hota and P. K. Srimani, Eds. Springer Berlin Heidelberg, feb 2013, vol. 7753, pp. 244–254. [Online]. Available: https://dx.doi.org/10.1007/978-3-642-36071-8 19 [16] ——, “Securestring 2.0 - a cryptosystem for computing on encrypted character strings in clouds,” in Networked Information Systems, ser. Fortschritt-Berichte Reihe 10, G. Eichler and R. Gumzej, Eds., vol. 826. VDI D¨usseldorf, jun 2013, pp. 226–240. [Online]. Available: https://dx.doi.org/10.13140/RG.2.1.4846.7521/3 [17] ——, “A second view on securestring 2.0,” in Distributed Computing and Internet Technology, ser. Lecture Notes in Computer Science, R. Natarajan, Ed. Springer International Publishing, feb 2014, vol. 8337, pp. 239–250. [Online]. Available: https://dx.doi.org/10.1007/ 978-3-319-04483-5 25 [18] G. Fahrnberger, D. Nayak, V. S. Martha, and S. Ramaswamy, “Safechat: A tool to shield children’s communication from explicit messages,” in Innovations for Community Services (I4CS), 2014 14th International Conference on, jun 2014, pp. 80–86. [Online]. Available: https://dx.doi.org/10.1109/I4CS.2014.6860557 [19] N. Ferguson and B. Schneier, Practical cryptography. Wiley, mar 2003. [20] H. Ganz and K. J. Borst, “Multiple-layer chat filter system and method,” nov 2012, uS Patent 8,316,097. [Online]. Available: https://www.google.com/patents/US8316097 [21] S. C. Hui, Y. He, and H. Dong, “Text mining for chat message analysis,” in Cybernetics and Intelligent Systems 2008 IEEE Conference on, sep 2008, pp. 411–416. [Online]. Available: https://dx.doi.org/10. 1109/ICCIS.2008.4670827 [22] A. Ibrahim, H. Jin, A. A. Yassin, and D. Zou, “Approximate keywordbased search over encrypted cloud data,” in e-Business Engineering (ICEBE), 2012 IEEE Ninth International Conference on, sep 2012, pp.
10
[23]
[24]
[25]
[26]
[27]
[28]
[29]
[30]
[31]
[32]
[33]
[34]
[35]
[36]
[37]
[38]
[39]
[40]
238–245. [Online]. Available: https://dx.doi.org/10.1109/ICEBE.2012. 46 M. Ishii, M. Izawa, R. Kataoka, M. Oku, and K. Ogawa, “Instant topic extraction from a text-based communication channel for seeing the world,” International Journal of Human-Computer Interaction, vol. 23, no. 1-2, pp. 51–69, dec 2007. [Online]. Available: https://dx.doi.org/10.1080/10447310701362900 R. Landsman, “Filter for instant messaging,” apr 2007, uS Patent App. 11/252,664. [Online]. Available: https://www.google.com/patents/ US20070088793 K. MacFarlane and V. Holmes, “Agent-mediated information exchange: Child safety online,” in Management and Service Science, 2009. MASS ’09. International Conference on, sep 2009, pp. 1–5. [Online]. Available: https://dx.doi.org/10.1109/ICMSS.2009.5302027 G. A. Miller, “Wordnet: a lexical database for english,” Commun. ACM, vol. 38, no. 11, pp. 39–41, nov 1995. [Online]. Available: https://dx.doi.org/10.1145/219717.219748 V. Mohite and S. Sharma, “An analysis of XMPP security,” oct 2008. [Online]. Available: http://openloop.com/education/classes/sjsu engr/ engr networksecurity/fall2008/preso/AnAnalysisofXMPPsecurity.pdf D. Nayak, M. Swamy, and S. Ramaswamy, “Supporting location information privacy in mobile devices,” in Distributed Computing and Internet Technology, ser. Lecture Notes in Computer Science, C. Hota and P. Srimani, Eds. Springer Berlin Heidelberg, feb 2013, vol. 7753, pp. 361–372. [Online]. Available: https://dx.doi.org/10.1007/ 978-3-642-36071-8 28 C. Peersman, F. Vaassen, V. Van Asch, and W. Daelemans, “Conversation level constraints on pedophile detection in chat rooms,” in CLEF (Online Working Notes/Labs/Workshop), sep 2012. [Online]. Available: https: //www.uni-weimar.de/medien/webis/events/pan-12/pan12-papers-final/ pan12-author-identification/peersman12-notebook.pdf N. Pendar, “Toward spotting the pedophile telling victim from predator in text chats,” 2012 IEEE Sixth International Conference on Semantic Computing, vol. 0, pp. 235–241, sep 2007. [Online]. Available: https://dx.doi.org/10.1109/ICSC.2007.32 L. Penna, A. Clark, and G. Mohay, “Challenges of automating the detection of paedophile activity on the internet,” in Systematic Approaches to Digital Forensic Engineering, 2005. First International Workshop on, nov 2005, pp. 206–220. [Online]. Available: https: //dx.doi.org/10.1109/SADFE.2005.4 B. Roth, “Topic extraction and relation in instant messaging,” Natural Language Processing Group, Stanford University, Tech. Rep., jun 2010. [Online]. Available: http://nlp.stanford.edu/courses/cs224n/2010/reports/ rothben.pdf W. W. Royce, “Managing the development of large software systems: concepts and techniques,” Proc. IEEE WESTCON, Los Angeles, pp. 1–9, aug 1970, reprinted in Proceedings of the Ninth International Conference on Software Engineering, March 1987, pp. 328-338. [Online]. Available: http://www.cs.umd.edu/class/spring2003/cmsc838p/ Process/waterfall.pdf P. Saint-Andre, “End-to-end signing and object encryption for the extensible messaging and presence protocol (XMPP),” RFC 3923 (Proposed Standard), oct 2004. [Online]. Available: https: //www.ietf.org/rfc/rfc3923.txt ——, “Mapping the extensible messaging and presence protocol (XMPP) to common presence and instant messaging (CPIM),” RFC 3922 (Proposed Standard), oct 2004. [Online]. Available: https://www.ietf.org/rfc/rfc3922.txt ——, “Extensible messaging and presence protocol (XMPP): Address format,” RFC 6122 (Proposed Standard), mar 2011. [Online]. Available: https://www.ietf.org/rfc/rfc6122.txt ——, “Extensible messaging and presence protocol (XMPP): Core,” RFC 6120 (Proposed Standard), mar 2011. [Online]. Available: https://www.ietf.org/rfc/rfc6120.txt ——, “Extensible messaging and presence protocol (XMPP): Instant messaging and presence,” RFC 6121 (Proposed Standard), mar 2011. [Online]. Available: https://www.ietf.org/rfc/rfc6121.txt Z. Shen, J. Shu, and W. Xue, “Preferred keyword search over encrypted data in cloud computing,” in Quality of Service (IWQoS), 2013 IEEE/ACM 21st International Symposium on, jun 2013, pp. 1–6. [Online]. Available: https://dx.doi.org/10.1109/IWQoS.2013.6550283 T. Suga, T. Nishide, and K. Sakurai, “Secure keyword search using bloom filter with specified character positions,” in Provable Security, ser. Lecture Notes in Computer Science, T. Takagi, G. Wang, Z. Qin, S. Jiang, and Y. Yu, Eds. Springer Berlin
THE PEER-REVIEWED VERSION IS AVAILABLE AT IEEEXPLORE.IEEE.ORG
Heidelberg, sep 2012, vol. 7496, pp. 235–252. [Online]. Available: https://dx.doi.org/10.1007/978-3-642-33272-2 15
11
