Ioana Chitoran

INTER-GESTURAL TIMING BETWEEN VOCALIC GESTURES AS A FUNCTION OF SYLLABLE POSITION: ACOUSTIC EVIDENCE FROM ROMANIAN

 Bonding Strength Model.

INTRODUCTION

A growing body of literature has provided articulatory and acoustic evidence for syllable position effects in several languages (see Kochetov 2002 for a review). We now have a good understanding of positional variation as manifested in the inter-gestural timing of consonants involving multiple oral gestures, and in the coordination of consonantal and vocalic gestures in onset and coda position [START_REF] Sproat | Allophonic variation in English /l/ and its implication for phonetic implementation[END_REF][START_REF] Keating | Effects of prosodic position on /t,d/ tongue/palate contact[END_REF][START_REF] Fougeron | Articulatory strengthening at edges of prosodic domains[END_REF][START_REF] Gick | The articulatory basis of syllable structure: a study of English glides and liquids[END_REF], Kochetov 2002, among others). A question which has not yet been explored concerns the relative timing of vocalic gestures as a function of syllable position. In this context, an interesting object of study is the traditional distinction between hiatus and diphthong, which is understood as a distinction in syllable affiliation, and is expected to be reflected in production differences.

A language suitable for investigating this question is one which contains both diphthongs and hiatus sequences involving the same vocalic gestures. Several Romance languages meet this criterion, and the present study focuses on Romanian. The distribution of prevocalic [j] and [i] in Romanian can generally be predicted from the location of stress, except for the very specific environment #C_V, where V is a non-high vowel. In this environment [j] is always present in native words: pjatr 'stone', pjerde 's/he loses', mjere 'honey', bjat 'poor', fjerbe 'it boils', vjerme 'worm'. The rising diphthongs [ja] and [je] above developed historically from the diphthongization of Latin // under stress. A preceding coronal or velar further absorbed the palatal glide, resulting in a very restricted distribution of the diphthongs in Modern Standard Romanian -they only occur between a labial and a stressed vowel.

In the #C_V environment the vowel [i] is present in lexical items that are mostly loanwords, or that contained an iV sequence in Latin: piastru 'piaster', pian 'piano', tiar 'tiara', diet 'diet', fiasko 'fiasco', siest 'siesta'. The hiatus pronunciation is not systematic, but is best described as variable, with [i] occasionally coming close to a glide. The presence of variation in hiatus sequences has been established in previous acoustic studies (Chitoran and[START_REF] Chitoran | Variability in hiatus resolution: a phonetic study of [CiV] sequences in two Romance languages[END_REF][START_REF] Hualde | Explaining the distribution of exceptional hiatus in Spanish and Romanian[END_REF], and was found to be related to position in the word and to distance from stress/pitch accent. Regardless of this variation, native speakers of Romanian are aware of the distinction between diphthongs and sequences, as demonstrated by their consistent agreement on the syllabification of these vocalic page 26 combinations: diphthongs are systematically syllabified as tautosyllabic (jV), while sequences are systematically syllabified with hiatus (i.V).

In this study I compare temporal and spectral differences between diphthongs and hiatus sequences, to determine whether they can be attributed to differences in articulatory timing corresponding to syllable affiliation. The results of this study are relevant for testing speech production models attempting to capture syllable affiliation. I propose an interpretation of these results in the framework of [START_REF] Browman | Competing constraints on intergestural coordination and self organization of phonological structures[END_REF] Bonding Strength Model, which was developed as a phonological model of the temporal patterning of consonantal and vocalic gestures within and across syllables.

In sections 2 and 3 I report and discuss the results of comparisons in duration (experiment 1), and in F2 values (experiment 2). The theoretical interpretation is proposed in section 4, followed by conclusions in section 5.

EXPERIMENT 1: DURATION Methods Data from four native speakers of Standard Romanian were recorded in a sound proof booth, using a Sony DAT recorder, at a sampling rate of 44kHz. The acoustic analysis was done using the Praat speech analysis software. Seven repetitions of each word were recorded, embedded in the frame sentence "Spune ____ de trej or j " 'Say ____ three times'. The sentences were read in randomized order. The data consist of diphthongs and hiatus sequences (a total of 161 per speaker). The words were also controlled for stress, number of syllables, the quality of the non-high vowel (mid or low), and as much as possible the quality of the flanking consonants.

Hypotheses

The comparison of the vocalic portion duration tests the hypothesis that the occasional glide percept in hiatus sequences is due to a shorter acoustic duration of [i] or of the transition between [i] and V. It is expected, however, that a contrast is maintained between diphthongs and hiatus sequences, and consequently the total duration of the monosyllabic diphthongs [jV] is hypothesized to be significantly shorter than that of disyllabic sequences [iV].

The comparison of the frication portion duration at the release of [p] tests the hypothesis that the occasional glide percept in hiatus sequences is due to a narrower constriction of [i]. The duration of frication is partly determined by the degree of constriction of the following vowel. Release into a narrow constriction generates more frication (in energy and duration) than release into a more open constriction. The [p] frication portion preceding the glide of a diphthong will therefore be significantly longer than that preceding the high vowel of a hiatus sequence. This measure is clearly not unambiguous, since it also includes some amount of aspiration at the release of a voiceless stop. However, a qualitative comparison of [p] releases before non-high vowels for the same speakers page 27

shows a much shorter, often absent, frication portion in those environments. Longer and higher energy frication may therefore be due primarily to release into a narrower constriction.

Results

Eight pairs of words containing hiatus sequences and diphthongs, like those illustrated in Table 1, were included in the total duration comparison (a total of 112 words per speaker). The total duration of the vocalic portion is evaluated as the dependent variable in an analysis of variance with Type as fixed factor (2 levels: sequence, diphthong). For all four speakers, hiatus sequences (iV) are significantly longer than diphthongs (jV), which suggests that contrast is maintained between them. This result is especially robust, given that the words containing sequences actually have an extra syllable compared to those containing diphthongs. The total duration results are presented in Table 2. An investigation of token-by-token duration values reveals interesting differences among individual speakers. Overall, all four speakers maintain a contrast between hiatus sequences and diphthongs, but they differ in the degree to which they do so. Speakers 1, 3, and 4 show a clear contrast. Speaker 2, however, shows much less separation. As many as 41 of her sequences are short enough to fall within the duration range of diphthongs. Impressionistically, her sequences often sound like diphthongs. These results suggest that duration is manipulated in the hiatus/diphthong contrast, as predicted by the first hypothesis. The occasional glide percept is due to a shorter acoustic duration of the vocalic portion. A qualitative comparison of the spectrograms shows a much shorter, often nonexistent steady-state portion for [j], and a shorter F2 transition from [j] to V. The F2 trajectory in diphthongs looks almost flat, closer to that of a monophthongal vowel.

For the comparison of the frication portion duration, 4 pairs of words were analyzed, namely those containing hiatus sequences and diphthongs preceded by [p] (a total of 56 words per speaker). Only two of the four speakers show a statistically significant difference between the duration of frication in [piV] vs. [pjV]. The results are presented in Table 3. As predicted by the second hypothesis, the frication portion is longer in diphthongs, before a narrower glide constriction, than in sequences, before a vowel constriction. However, since the difference is statistically significant for only two of the speakers, I conclude that constriction size is less important in maintaining a hiatus/diphthong contrast.

Proceedings of the 6th International Seminar on Speech Production, Sydney, December 7 to 10, 2003.

page 28

EXPERIMENT 2: F2 ONSET

Methods

Five pairs of words were used for spectral analysis: fjart/fiasko, pjatr/piastru, pjar/pianu, pjaz/pianu, pjard/piastru, a total of 70 words per speaker. The analysis consists of running formant tracks over the vocalic portion of each sequence and diphthong, and extracting the value of the second formant at the onset of the sequence/diphthong. A short-term spectral analysis is performed in a 25 ms window, at a time step of 2.5 ms. For each analysis window the algorithm in Praat computes the LPC coefficients. The F2 values extracted by the algorithm were compared to the corresponding spectrograms. Deviating values and the corresponding words were excluded from the statistical analysis. For each sequence/diphthong pair, the formant tracks generated for each individual token (14 per pair) were then overlaid on top of one another and saved to a picture file, for overall qualitative comparison.

Hypothesis

It is hypothesized that hiatus sequences and diphthongs will show different coarticulatory patterns with the preceding consonant. The occasional diphthong percept in sequences is predicted to be due to specific coarticulatory patterns between the consonant and the following high vowel, as manifested in the F2 value at the onset of the vocalic portion. Specifically, it is predicted that the F2 value will be higher before [i] than before [j]. An onset consonant is expected to show more coarticulation with the nucleus vowel [i], seen in a higher F2 onset value, corresponding to a high front vowel. In a diphthong, the nucleus is a non-high vowel, and coarticulation with this vowel is expected to lower the F2 onset value even across an intervening [j].

Results

The F2 value at the onset of the vocalic portion is evaluated as the dependent variable in an analysis of variance with Type as fixed factor (2 levels: sequence, diphthong). As predicted, the F2 onset values are higher in hiatus sequences than in diphthongs, although for one of the four speakers the difference is not statistically significant. The results are reported in Table 4. Interestingly, speaker 2, whose difference in F2 values is not statistically significant, is the same speaker whose sequences and diphthongs showed less of a separation in total duration (Table 2). The different patterns of two representative speakers are illustrated in Figures 1 and2 below. These are plots of the vocalic portion duration and F2 onset value. They show overlapping values for Speaker 2 (Figure 1), whereas for speaker 3 they tend more toward a bimodal distribution (Figure 2). The results support the hypothesis, suggesting that CV coarticulatory patterns as reflected in the onset value of F2 are important in encoding a sequence/diphthong contrast. A qualitative examination of the spectrograms reveals several other differences. In addition to the flatter F2 trajectory in [jV], the [p] release burst in [pja] is followed by a short formant rise into [j]. In the sequence [pia] the same formant rise is longer and higher. The lower F2 values at the onset of a diphthong suggest the presence of target undershoot in the glide as opposed to [i].

Proceedings of the 6th

THEORETICAL INTERPRETATION

The theoretical interpretation must explain why, given two contrasting linguistic elements -diphthongs and hiatus sequences -one of them allows for occasional variation which leads to its perceptual confusion with the other. I propose that a suitable model for the interpretation of these data is [START_REF] Browman | Competing constraints on intergestural coordination and self organization of phonological structures[END_REF] Bonding Strength Model. The authors propose that temporal patterning is the result of weighted competition between a number of gestural coordination relations.

The relevant one here is the C-V relation, which defines syllable onsets. According to it, onset consonantal gestures tend to be produced simultaneously with the nucleus vocalic gesture.

Proceedings of the 6th International Seminar on Speech Production, Sydney, December 7 to 10, 2003.

page 30

According to this model, in hiatus sequences only one coordination relation is present, between the onset C and the high vowel [i]. In diphthongs, which are tautosyllabic, the C and the glide form a complex onset, which as a whole bears a relation to the following V. Two coordination relations are therefore present in diphthongs: a C-V and a glide-V relation. Consequently, in hiatus sequences the relative timing between gestures is more variable and less tightly controlled than in diphthongs, where two coordination relations are active, and the onset as a whole bears a relation to V.

The model predicts that a possible source for the occasional glide percept in sequences lies in the absence of a [i]-V relation across the syllable boundary. In sequences, the V gesture is thus allowed to have an early or a late onset relative to the [i] gesture. If it starts early, it results in a shorter or absent [i] steady-state, and a shorter vocalic portion overall. In diphthongs the C-V and [j]-V relations reinforce each other, and the C and [j] gestures each tend to be timed simultaneously with the V gesture. This coordination pattern results in tight articulatory timing, and an early onset of the V gesture. The same configuration can explain the lower F2 onset values in diphthongs. By allowing a very short time window in which a glide can be acoustically realized, it may be responsible for the F2 target undershoot in [j].

CONCLUSIONS

In this study I compared duration and spectral properties of Romanian hiatus sequences and diphthongs. Based on the results, it was established that the difference between them is manifested primarily in two acoustic parameters: the vocalic portion duration and the F2 value at the onset of the vocalic portion. These acoustic differences can be explained by differences in articulatory timing, with looser timing in hiatus sequences, allowing for variation. A consequence of this variation is a possible early or late onset of the V gesture relative to the [i] gesture. An early onset can produce a glide percept. The results of this production study still have to be supported by perception tests.

Figure 1 .Figure 2 .

 12 Figure1. Plot of vocalic portion duration (x axis) and F2 onset value (y axis) for speaker 2.This speaker shows more overlap between diphthongs and hiatus sequences.

Table 1 .

 1 Sample data

	diphthongs	hiatus
		sequences
	fjerbe	fiordu
	fjart	fiasko
	pjar	pianu
	bjete	dieta
	pjatr	piastru
	mjere	miopu

Two duration measurements were taken, based on waveform and wideband spectrogram. The total duration of the vocalic portion [jV] and [iV] was measured from the onset of F1 to the offset of F2. The duration of high energy frication at the release of initial [p] into the narrow constriction of [i] or

[j]

was measured from the end of the [p] release burst to the onset of F1 of [i] or

[j]

.

Table 2 .

 2 Vocalic portion duration in sequences vs. diphthongs (ms). Means and standard deviations.

		Sp1 (DS)	Sp2 (LD)	Sp3 (BS)	Sp4 (AG)
	Sequences	185	169	223	220
	(iV)	(24.16)	(25.91)	(33.69)	(35.53)
	Diphthongs	128	151	135	173
	(jV)	(21.77)	(28.38)	(21.26)	(30.67)
	Effect of	F(1,109)=	F(1,110)=	F(1,103)=	F(1,110)=
	Type	169.418	12.219	243.325	55.449
		p<.001	p<.01	p<.001	p<.001

Table 3 .

 3 Duration of high energy frication at the release of [p] in sequences vs. diphthongs (ms). Means and standard deviations.

		Sp1 (DS) Sp2 (LD) Sp3 (BS)	Sp4 (AG)
	Sequences	21	44	23	17
	(iV)	(9.34)	(19.8)	(13.8)	(7.31)
	Diphthongs	26	48	35	54
	(jV)	(16.45)	(7.53)	(10)	(21)
	Effect of			F(1,52)=	F(1,51)=
	Type	p>.05	p>.05	12.73	71.639
				p<.01	p<.001

Table 4 .

 4 F2 values at the onset of the vocalic portion (Hz).

	Means and

ACKNOWLEDGEMENTS

I thank Louis Goldstein, José Ignacio-Hualde, John Kingston, and Donca Steriade for valuable comments on this study. Jesse Beach has been instrumental in writing Praat scripts. All remaining errors are my own.


Ioana Chitoran
email: ioana.chitoran@univ-paris-diderot.fr

Alina Maria Ciobanu
email: alina.ciobanu@my.fmi.unibuc.ro

Liviu P Dinu
email: ldinu@fmi.unibuc.ro

Vlad Niculae
email: vniculae@mpi-sws.org

Using a Machine Learning Model to Assess the Complexity of Stress Systems

Keywords: stress prediction, Romanian stress, syllabication, sequence tagging

We address the task of stress prediction as a sequence tagging problem. We present sequential models with averaged perceptron training for learning primary stress in Romanian words. We use character n-grams and syllable n-grams as features and we account for the consonant-vowel structure of the words. We show in this paper that Romanian stress is predictable, though not deterministic, by using data-driven machine learning techniques.

Introduction

The goal of this study is to use a machine learning approach to test the learnability of the stress system of Romanian, and at the same time to verify the analysis of stress proposed by linguists. Romanian is a challenging case study, because at first glance stress appears to be freely placed, no obvious patterns emerge, suggesting that the only way it can be learned is as part of individual lexical items. The algorithm presented here relies on the analysis of primary stress proposed by [START_REF] Chitoran | Prominence vs. rhythm: The predictability of stress in Romanian[END_REF], which makes crucial use of morphological information to reveal predictable patterns of stress assignment. This analysis is quite complex, and the question of its learnability is an important one. We are specifically interested in determining whether certain parts of the lexicon are less learnable than others, and to analyze their properties. Syllable structure and stress pattern prove extremely useful in text-to-speech synthesis (TSS), as they provide valuable knowledge with regard to pronunciation modeling, and were, therefore, thoroughly investigated [START_REF] Damper | Evaluating the pronunciation component of text-to-speech systems for English: a performance comparison of different approaches[END_REF][START_REF] Demberg | Phonological Constraints and Morphological Preprocessing for Grapheme-to-Phoneme Conversion[END_REF][START_REF] Dou | A Ranking Approach to Stress Prediction for Letter-to-Phoneme Conversion[END_REF][START_REF] Trogkanis | Conditional Random Fields for Word Hyphenation[END_REF][START_REF] Bartlett | Automatic Syllabification with Structured SVMs for Letter-to-Phoneme Conversion[END_REF][START_REF] Petrisor | An Approach to Syllables via some Extensions of Marcus Contextual Grammars[END_REF][START_REF] Liviu | A Parallel Approach to Syllabification[END_REF][START_REF] Toma | Automatic rule-based syllabication for Romanian[END_REF].

The Stress System of Romanian

Traditional Romanian grammars treat primary stress as unpredictable, and therefore lexically assigned (most recently Panȃ Dindelegan (2013)). Apparent minimal pairs such as ácele (the needles) and acéle (those, fem.) support this conclusion. [START_REF] Chitoran | Prominence vs. rhythm: The predictability of stress in Romanian[END_REF] argues, however, that stress is in fact to a large extent predictable if one takes into account its close dependence on the morphology of the language, specifically the distribution of lexical items by their part of speech and their internal morphological composition. Once this type of information is considered, unpredictability is significantly reduced. For example, if we consider the morphological structure in the pair ácele (noun) -acéle (pronoun), the first lexical item has the structure ac]-e-le (needles) consisting of the root ac, the plural marker -e, and the feminine plural definite article -le. The second item has the structure ace]-le (those, fem.), consisting of a pronoun form and the same definite article -le. Once the forms are decomposed, we see that both bear stress on the final syllable of the root. Stress assignment, therefore does not include inflectional material that lies beyond the square bracket. Such a fine-grained linguistic analysis shows that a significant amount of unpredictability can be eliminated if the domain of stress is computed over the morphological composition of the lexicon. Nevertheless, lexical marking cannot be entirely dispensed with, because two separate stress patterns coexist in the Romanian lexicon, as a result of historical changes and lexical borrowings in different language contact situations. Each stress pattern is regular and predictable, but no generalizations can be drawn regarding which lexical items belong to which pattern. [START_REF] Chitoran | Prominence vs. rhythm: The predictability of stress in Romanian[END_REF] identifies the regularities in each pattern by considering both phonological and morphological factors. Generalizations emerge when lexical items are grouped by parts of speech. This organization of the data reveals unifying generalizations for verbs, adjectives, nouns, regarding:

• the distance of the stressed syllable from the right edge of the word;

• the shape of the final syllable -CV or CVC.

We present the relevant generalizations organized by part of speech and the shape of the final syllable for each stress pattern.

Nouns and adjectives. Verbs. The stress pattern of verbs is related to the conjugation class. Romanian has four verb conjugations. In the following infinitive forms, the final theme vowel which marks the conjugation class is underlined: (I) cântá (to sing), (II) vedeá (to see), (III) spúne (to say), (IV) dormí (to sleep). Verbs of the first, second, and fourth conjugation stress the theme vowel, while third conjugation verbs stress the root. This alternation in the location of stress between the theme vowel and the root is maintained throughout verb paradigms. As for nouns and adjectives, the stress domain excludes inflectional markers and contains only the root and the theme vowel. Consider, for example, the present tense forms of (I) cânta (to sing). The stressed vowel is in bold:

(1) Pattern 1 -cântá (I) cânt] I sing cânt ¸] j you sing cânt] ȃ s/he sings cânt-ȃ] m we sing cânt-a] t ¸j you sing cânt] ȃ they sing

The main generalization for the verb system is: stress the rightmost syllable of the stress domain. When the theme vowel is present, it belongs to the rightmost syllable and it is always stressed. Otherwise the rightmost syllable of the root is stressed. As for nouns, a second stress pattern is found for verbs. For example (I) cumpȃrá (to buy) is conjugated as follows:

(2) Pattern 2 -cumpȃrá (I) cumpȃr]

I buy cumper] i you buy cumpȃr] ȃ s/he buys cumpȃr-ȃ] m we buy cumpȃr-a] t ¸i you buy cumpȃr] ȃ they buy

In the second pattern stress falls on the penultimate syllable of the root when the theme vowel is absent, and on the theme vowel when it is present.

Questions

We are first of all interested in testing the general learnability of this analysis, and determining whether certain subpatterns are more difficult to identify than others. The proposed linguistic analysis did not include words containing glides. This gives us the opportunity to extend the algo-rithm as is to these additional forms and to test its performance. This paper also relies on the assumption that the stress system of Romanian is predictable from the distribution of the lexical items among parts of speech. Unlike Chitoran's analysis, our system does not factor out inflections. When applied to fully inflected forms it detects a much higher number of stress pattern classes, with much more complex structures. For instance, while Chitoran distinguishes 6 patterns for disyllabic words (CV-C VC,CVC-C VC, CV-C VCC, CVC-C VCC, C V-CVC and C VC-CVC), we automatically identify 447 distinct patterns for disyllabic words in the RoSyllabiDict dataset (which is described in detail in Section 4), including Chitoran's patterns 1 and 2. We account for type words in our analysis. Almost all of these patterns are not deterministic with regard to stress assignment, that is, the dictionary indicates more than on possible stress location. For example, for the CCV-CVC pattern, which has 1,390 occurrences in our dataset, we identify two positions for stress placement: CCV-C VC (1,017 occurrences) and CC V-CVC (373 occurrences).

Data

We run our experiments for Romanian using the RoSyllabiDict [START_REF] Barbu | Romanian Lexical Data Bases: Inflected and Syllabic Forms Dictionaries[END_REF] dictionary, which is a dataset of annotated words comprising 525,528 inflected forms for approximately 65,000 lemmas. For each entry, the unsyllabified form, the syllabication, the stressed vowel (and, in case of ambiguities, also grammatical information or type of syllabication) are provided. For example, the word copii (children) has the following representation:

<form w="copii" obs="s."> co-píi</form>

We investigate stress placement with regard to the syllable structure and we provide in Table 1 the percentages of words having the stress placed on different positions, counting syllables from the beginning and from the end of the words as well. [START_REF] Dinu | On the Behavior of Romanian Syllables Related to Minimum Effort Laws[END_REF] show that the probability distribution of the n-syllabic lemmas in RoSyllabiDict follows a Poisson distribution. We investigate the C/V structure of the words in RoSyl-labiDict using raw data, i.e., a, ȃ, â, e, i, î, o, u are always considered vowels and the rest of the letters in the Romanian alphabet are considered consonants. Thus, we identify a very large number of C/V structures, most of which are not deterministic with regard to stress assignment, having more then one choice for placing the stress. For example, for CCV-CVC structure (1,390 occurrences in our dataset) there are 2 associated stress patterns: CCV-C VC (1,017 occurrences) and CC V-CVC (373 occurrences). Words with 6 syllables cover the highest number of distinct C/V structures (5,749). There are 31 C/V structures (ranging from 4 to 7 syllables) reaching the maximum number of distinct associated stress patterns (6).

For our experiments, we discard words which do not have the stressed vowel marked (3,430 words), compound words having more than one stressed vowel (1,668 words) and ambiguous words, either regarding their part of speech or type of syllabication, marked in the dataset in the obs. field (20,123 words).

Romanian Stress Prediction

We address the task of stress prediction for Romanian words as a sequence tagging problem, extending the method proposed by [START_REF] Maria Ciobanu | Predicting Romanian Stress Assignment[END_REF]. In this paper, we account only for the primary stress, but this approach allows further development in order to account for secondary stress as well.

In order to investigate the predictability of the stress system of Romanian, we employ Chitoran's hypothesis regarding the dependence of the stress placement on the morphology of the language; we conduct a detailed experiment dividing the Romanian words based on their part of speech and for verbs we introduce a further level of granularity by accounting for the conjugation class, as described in Section 2. We train and evaluate four systems for the automatic prediction of stress placement for Romanian words: a "majority-class" type of baseline and three systems using averaged perceptron for parameter estimation: a sequential model with character n-gram features and two cascaded models; each consists of two sequential models trained separately (one for syllabication and another one for stress prediction), the output of the first being used as input for the second. One of the cascaded models uses character n-grams and the other uses syllable n-grams and both systems employ additional information regarding stress placement and word structure.

Baseline

We use a "majority class" type of baseline which employs the C/V structures described in Section 4. and assigns, for a word in the test set, the stress pattern which is most common in the training set for the C/V structure of the word, or places the stress randomly on a vowel if the C/V structure is not found in the training set. For example, the word copii (meaning children) has the following C/V structure: CV-CVV. In our training set, there are 659 words with this structure and the three stress patterns which occur in the training set are as follows: CV-C VV (309 occurrences), C V-CVV (283 occurrences) and CV-CV V (67 occurrences). Therefore, the most common stress pattern CV-C VV is correctly assigned, in this case, for the word copii.

Sequential Model

We use a simple tagging structure for marking primary stress. The stressed vowel receives the positive tag 1, while all previous characters are tagged 0 and all subsequent ones 2. This structure helps enforce the uniqueness of the positive tag. The features used are character n-grams up to n = W in a window of radius W around the current position. For example, if W = 2, the feature template andc[1:2]. If the current character is the fourth of the word dinosaur, o, the feature values would be i, n, o, s, a, in, no, os, sa.

consists of c[-2], c[-1], c[0], c[1], c[2], c[-2:-1], c[-1:0], c[0:1],

Cascaded Model with Character n-grams

The cascaded model consists of two sequential models, the output of the first one being used as a form of input (features) for the second one. We use a syllabication model to predict syllable boundaries and for stress prediction we use another one, similar to the baseline and including two additional types of features:

• syllable structure features regarding vowel/consonant sequences: n-grams using, instead of characters, markers for consonants (C) and vowels (V);

• binary indicators of the following positional statements about the current character:

exactly before/after a split; in the first / second / third / fourth syllable of the word, counting from left to right; in the first / second / third / fourth syllable of the word, counting from right to left.

Following the method proposed by [START_REF] Liviu | Romanian Syllabication Using Machine Learning[END_REF], the syllabication prediction is performed with another sequential model of length n -1, where each node corresponds to a position between two characters. Based on experimenting and previous work, we adopted the Numbered NB labeling [START_REF] Bartlett | Automatic Syllabification with Structured SVMs for Letter-to-Phoneme Conversion[END_REF]. Each position is labeled with an integer denoting the distance from the previous boundary. For example, for the word diamond, the syllable (above) and stress annotation (below) is:

d i a m o n d 1 0 0 1 2 3 0 1 2 2 2 2 2
The features used for syllabication are based on the same principle, but because the positions are in-between characters, the window of radius W has length 2W instead of 2W + 1. For this model we used only character n-grams as features.

Cascaded Model with Syllable n-grams

This cascaded model is similar to the previous one, but uses, for the second sequential model, syllable n-grams instead of character n-grams. For example, if the current character is the second o in accommodation and W = 2, the feature values would be ac, com, mo, da, tion, accom, commo, moda, dation. For training and model selection, we use the gold syllable structure from the dataset.

Experiments and Results Analysis

In this section we present and analyse the main results drawn from our research on Romanian stress assignment.

Experiments

We split the dataset in two subsets: train set (on which we perform cross-validation to select optimal parameters for our model) and test set (with unseen words, on which we evaluate the performance of our system). We use the same train/test sets for the two sequential models, but they are trained independently. The output of the first model (used for predicting syllabication) is used for determining feature values for the second one (used for predicting stress placement) for the test set. The second model is trained using gold syllabication (provided in the dataset) and we report results on the test set in both versions: using gold syllabication to determine feature values and using predicted syllabication to determine feature values. The results with gold syllabication are reported only for providing an upper bound for learning and for comparison. We use averaged perceptron training [START_REF] Collins | Discriminative Training Methods for Hidden Markov Models: Theory and Experiments with Perceptron Algorithms[END_REF] from CRFsuite [START_REF] Collins | Discriminative Training Methods for Hidden Markov Models: Theory and Experiments with Perceptron Algorithms[END_REF]. For the stress prediction model we optimize hyperparameters using grid search to maximize the 3fold cross-validation F1 score of class 1, which marks the stressed vowels. We search over {2, 3, 4} for W ,and over {1, 5, 10, 25, 50} for the maximum number of iterations.

For stress prediction systems, the optimal window radius W was 4 and the maximum number of iterations 50 when using character n-grams, and when using syllable n-grams the optimal window radius W was 3 and the maximum number of iterations 50. We investigate, during grid search, whether employing C/V markers and binary positional indicators improve the cascaded systems' performance. It turns out that in most cases they do. For the syllabication model, the optimal hyperparameters are 4 for the window radius and 50 for the maximum number of iterations. We evaluate the cross-validation F1 score of class 0, which marks the position of a hyphen. The system obtains 0.995 instance accuracy for predicting syllable boundaries. Further, we divide words based on their part of speech (nouns, adjectives and verbs -one group for each conjugation class) and we train and evaluate the cascaded models independently on each category in the same manner as we did for the entire dataset. We decided to use crossvalidation for parameter selection instead of splitting the data in train/dev/test subsets in order to have consistency across all models, because some of these word categories do not comprise enough words for splitting in three subsets (verbs of the fourth conjugation class, for example, have only 1,385 instances). In Table 2 we provide the number of words in each category for the RoSyllabiDict dataset. The results drawn from our research are reported and analysed in the following subsections.

POS

Results Analysis

In Table 3 we report the results of all models on the entire RoSyllabiDict dataset. We report word-level accuracy (instance accuracy), that is, we account for words for which the stress pattern was correctly assigned. As expected, all sequential models significantly outperform the baseline.

Error Analysis

In Table 6 we report the distribution of the words for which the best performing system (the cascaded model with gold syllabication and character n-grams) did not correctly predict the stress placement, counting syllables from right to left. For most verbs (first, second and third conjugation) and for nouns, the stress is most frequently misplaced when it is located on the penultimate syllable (the syllable from right to left). For adjectives, almost half of the errors occur when the stress is placed on the last syllable (48.08 %), while for verbs of the fourth conjugation more than half of the errors occur when the stress is placed on the antepenultimate syllable (the third syllable from right to left).

Conclusion and Future Work

Syllable structure is important and helps the task of stress prediction. This is consistent with linguistic analysis, which shows that the syllable is the stress-bearing unit. The cascaded models using gold syllabication outperform their equivalent systems with predicted syllabication by only very little. For real applications, such systems, which require less or no linguistic knowledge are needed for words that cannot be found in datasets, and therefore gold splits are not available. We intend to evaluate the system on other languages, as there is nothing language-specific in the pipeline.

Both the linguistic and the machine learning approach presented here test the hypothesis that the stress system of Romanian is predictable. They both reach the conclusion that only parts of it are. The main difference between the two lies in the number of different patterns identified. [START_REF] Chitoran | Prominence vs. rhythm: The predictability of stress in Romanian[END_REF] reduces the number of patterns by considering fine details of word structure. The learning model, on the other hand, is applied to raw data, to citation forms moreover presented to the model in written form. It has thus identified a larger number of separate patterns. This discrepancy in the results motivates further work that would investigate the possibility of adapting the learning model to more fine grained linguistic analysis.

Table 1 :

 1 Stress placement for RoSyllabiDict.

	Syllable %words	Syllable %words
	1 st	5.59	1 st	28.16
	2 nd	18.91	2 nd	43.93
	3 rd	39.23	3 rd	24.14
	4 th	23.68	4 th	3.08
	5 th	8.52	5 th	0.24
	(a) counting syllables from	(b) counting syllables from
	the beginning of the word	the end of the word

Table 2 :

 2 Number of words in each subcategory forRoSyllabiDict.

		Conj.	words
		1	112,949
	Verbs	2 3	7,521 1,385
		4	59,768
	Nouns	-	266,987
	Adjectives	-	97,169

Table 3 :

 3 Instance accuracy for stress prediction.

	The best perfermonce is obtained by the cascaded model
	with gold syllabication and character n-grams, which ob-
	tains 0.975 instance accuracy.
	Model				Instance accuracy
	Baseline				0.637
	Sequential				0.974
	Cascaded (gold, character n-grams)	0.975
	Cascaded (predicted, character n-grams) 0.973
	Cascaded (gold, syllable n-grams)	0.955
	Cascaded (predicted, syllable n-grams)	0.684
	Further, we perform an in-depth analysis of the cascaded
	models' performance on part of speech based categories.
	The test results of both cascaded systems for RoSyllabiDict
	subsets split based on part of speech are reported in Ta-
	bles 4, 5, 7 and 8. We account for word-level correct stress
	placement (instance accuracy) and character-level correct
	stress placement (item accuracy). The cascaded models us-
	ing gold syllabication outperform their equivalent systems
	with predicted syllabication by only very little. For real ap-
	plications, such systems, which require less or no linguistic
	knowledge are needed for words that cannot be found in
	datasets, and therefore gold splits are not available.
	POS	Conj.	Item accuracy accuracy predictions Instance correct
		1	0.999	0.997	56,324
	Verbs	2 3	0.998 0.999	0.996 0.997	3,749 691
		4	0.999	0.999	30,358
	Nouns	-	0.993	0.979	130,746
	Adjectives -	0.997	0.992	48,194

Table 4 :

 4 Results for stress prediction system with character n-grams and gold syllabication for feature extraction.

	POS	Conj.	Item accuracy accuracy predictions Instance correct
		1	0.999	0.997	56,320
	Verbs	2 3	0.998 0.999	0.994 0.997	3,743 691
		4	0.999	0.998	30,333
	Nouns	-	0.993	0.979	130,696
	Adjectives -	0.997	0.992	48,195

Table 5 :

 5

Results for stress prediction system with character n-grams and predicted syllabication for feature extraction.

Acknowledgements

The authors thank the anonymous reviewers for their helpful and constructive comments. The contribution of the authors to this paper is equal. Research supported by a grant of the Romanian National Authority for Scientific Research, CNCS UEFISCDI, project number PN-II-ID-PCE-2011-3-0959.

POS

The cascaded model with character n-grams obtains better performances overall and for each part of speech category as well. Highest overall instance accuracy is 0.975, obtained by the cascaded model with gold syllabication. As expected, when words are divided in groups based on their parts of speech, the systems are able to predict stress placement with higher accuracy. Best performances are obtained for verbs (all four conjugations), followed by adjectives, while stress placement for nouns is predicted with lowest accuracy. The system with character n-grams substantially outperforms the system with syllable n-grams in both version, with gold and predicted syllabication as well.


Franck Bucheron

Arnaud Tisserand
email: arnaud.tisserand@irisa.fr

Louis Rilling

Hardware/Software Support for Securing Virtualization in Embedded Systems

Keywords: TCG, TPM, Embedded security, Cryptographic primitives, Virtualization, Embedded systems, Xen hypervisor, Hardware-software codesign

As far as one is concerned by security in virtual embedded systems, one can say that many ideas or implementations exist today but not really as a global solution and not really in the open-source world. Our goal is to bring a security solution up-to-date and new to build-up a solution from the hardware to an end-user application located in a virtual machine (VM). The idea of this article is to focus on the lack of secure solutions that can help virtualization and communication which can be implemented on new hybrids (Core + FPGA) development platforms. On one side, these boards are featured with processors that do not have virtualization extensions but are powerfull enough to really support hypervisors and their guests. On the other side some virtualization solutions presently exist for ARM processors but they only refer to TrustZone for their (hardware) security. These hybrid boards can offer us more: we have read some recents and up-to-date specifications made by a consortium to help the implementation of hardware security. In this area, FPGA can help in securing virtualization. But we must notice that, for now, all has been made for Intel/AMD architectures and for a lone operating system. Even so, the whole propositions are too complex to be implemented on embedded systems. So, we will have to use some capabilities in hardware development and make software rearrangements to help us to design a functional solution.

Introduction

Up to some years ago, mainly high-performance processors, such as those in servers and desktops, were powerful enough to support virtualization. This was mainly used at software level to provide isolation, security services and resources sharing. Today, even processors for embedded systems can also efficiently support virtualization. But on top of isolation and protection against software attacks, embedded systems have also to face hardware attacks such as side channel attacks (SCAs). Hence, virtualization for embedded systems requires a combined hardware/software (HW/SW) approach. In this paper, we first provide an important review and analyze state-of-art solutions. Second, we describe our own solution. We study an embedded virtualization solution based on HW IPs and a SW stack for efficiently protecting the system against SW attacks. Security against SCAs comes from the use of optimized and SCA-protected hardware IPs for primitives such as symmetric/asymmetric cryptography and true random number generation (TRNG). Using this HW/SW approach, we expect better performances, security and lower power consumption compared to software solutions. Our system is implemented in a Zynq-7000 HW/SW platform composed of a processor (ARM Cortex-A9 dual-core) and a FPGA (Artix-7) in the same device. For the SW stack, we use a derived version of the Xen hypervisor. In order to offer efficient, robust and low-power integrity, confidentiality and authentication primitives, we use a minimal list of existing HW IPs: AES (256 bits) for symmetric encryption/decryption, ECC (between 192 and 256 bits), RSA (2048 bits), TRNG, SHA-2 (256 bits). In addition to these HW IPs, we have to add a few other HW blocks: I/O interface between HW and SW, various internal memories (for Platform Configuration Registers (PCR) and keys), control and execution engine (for the HW part of implemented security policies). At the SW level, we adapted a Xen-like hypervisor to our HW architecture. Our SW code links the various virtual machines (VMs), the management VM (Dom0) and the hardware architecture. The proposed HW architecture and SW stack allows the end user to launch VMs where the executed code is trusted (i.e. verified and the user is granted) and the manipulated data are also trusted (i.e. integrity is ensured and only authorized users have access to these data inside the complete HW/SW platform). In a first part of this document we will look at the state of the art in our domain of research to get a strong idea of what can be done including the threats of these implementations or proposed implementations. In a second part we will explain the choices made for this work and explain the design of the proposed solution (hardware and software). In a third part of this document, we will conclude and present the work still in progress. Finally, we will make plans about future developments.

State of the Art

In a global point of view, we will have to look at three domains: hardware, existing software virtualization solutions in the open-source world and concepts of trusted computing which can link both of them. Then, we will study the threats in those domains that one must tackle in our solution.

FPGA and ARM Cores

To deal with embedded systems, one has two possibilities: ASICs and FPGAs. ASICs are non-programmable but they can use software intensively. They are included in "ready-to-use" systems on chip (SoCs) with their board support package (BSP) and software distributions the user can immediatly install. Most popular are linux-based ones. We can find different sorts of CPU inside: Intel's Atom, AMD's G-series, Freescale's PowerPC e300, ARM's Cortex-M series or adaptated IP cores for specific usages. These SoCs fit very well for a general use or students researchs. Some of them are designed for special purposes and include some safety/security like cryptographic accelerators, trusted boot capabilities, efuses possibilities. But we don't get all the detailed specifications for these elements and they have few or no programming capacities. At least they can't upgrade their software ou hardware due to weaknesses (newly discovered vulnerabilities, bugged soft or hard implementation and age). On the other side, FPGAs are black boards and have to be implemented from scratch with all the needed IP plus another special software development (i.e the firmware) for the board support package. For a standalone FPGA board an extra softcore processor should be implemented on it. For a combined development, one can plug a FPGA daughter card into a board containing a processor which result in connections that must be secured between the board and the FPGA. This may cause latencies. To help using FPGAs, few years ago, some hybrid platforms have been produced (Arria or Cyclone based from Altera and Artix or Kintex from Zynq-7000 Xilinx). These two boards have approximately the same architecture for the first designs depending upon the exact reference as shown in figure 1. The Zynq-7000 is the only development board immediatly avaliable at lowcost on the market at the end of this state of the art. All the components are present to consider the realization of projects that had never been made before on such a board. They can provide a secure/authenticated boot with Xilinx credentials which can be replaced by user-provided secure boot up to a certain extent. They also offer partial reconfiguration possibilities even if it must be manually done with the last Vivado version (2014.3) and one has to purchase a special license for it. On these boards, one can boot the device under several modes but in this work we only consider secure modes (encrypted and signed). And for this boot mode, one have again 4 possibilities (Flash, QSPI, NAND and NOR). The BootROM is on the processing system (PS) side along with the hash of the RSA public key (for authentication) and 256 kB. of on-chip memory (OCM). On the programmable logic (PL) side one find 2 engines: one AES-256 for decryption purposes and one HMAC SHA-256 for authentication purposes plus efuses, battery backed RAM (BBRAM) and configuration registers. The secure flow of booting, on figure 2, depends on two operation. One the PC side, the bootgen tool generates first the HMAC which is followed by AES encryption then the hash of the partition will be signed with RSA private key. On the Zynq side, the bootROM code will authenticate the FSBL's partition and the FSBL will then authenticate the partition, decrypt it and authenticate it. Considering these hybrid boards, both work with an ARM processors designed with 2 Cortex-A9. ARM "secure extension" called TrustZone is present. But, mainly because this extension is "secure", we don't know if the PS of the Zynq-7000 allow playing with such a device and if it does, under which conditions of intellectual property. The Cortex-A9 CPU is the last one of the ARMv7 family which does not have virtualization extensions. New ARM Cortex-A15 and the next-to-come ARMv8 family will have them with a new processor mode helping in hypervisor execution (HYP). This new processor execution mode introduces a 2-walk memory page translation. Another add-on, the large physical address extension (LPAE), will allow to have more than 4 GB of memory but is not avaliable on the Zynq.

Virtualization on ARM Cores

Virtualization is not a new idea. Its concepts have been well defined in a book: Virtual Machines [START_REF] Smith | Virtual machines[END_REF]. Unfortunately, nearly all the functional hypervisors have been made for the INTEL x86 architecture. There are few hypervisors working on ARM cores and very few of them are open-source. One keep closed-source commercial OS out of the scope of our work mainly because their hypervisors are licensed and modifications impossible for a research work. First of all, one must remind that the used type of virtualization will depend on what ARM core family is used. On ARMv7 family, only software virtualization will be possible. On ARMv7+ (Cortex-A15) and ARMv8 family, both software and hardware virtualization can be considered. Sierraware1 has developped Sierra hypervisor which runs on ARM cores. The sources can be downloaded but the Zynq-7000 version has only a binary version. No further implementation (i.e. modifications of kernel sources) will be possible with this hypervisor. Xtratum2 is an other hypervisor running on ARM platforms but it is very difficult to get the source code. The version we worked on was the 3.2 one and vTPM were implemented on software. Xen ARM (paravirtualized or not)3 developed a well suited hypervisor for ARM cores but nothing for the Zynq yet. We have no time to implement such a version. An implementation of Xen on an ARM-base smartphone called "secure Xen" has been made in 2008 that shows to be a valuable solution. This document is very helpful in terms of howto [START_REF]Secure xen on arm user's guide[END_REF]. More than this, Samsung designed a new extension on Xen for ARMv7 cores to enable a divided user mode and allow the guest OS be "more isolated" from a guest application [START_REF] Joo-Young | Xen on arm: System virtualization using xen hypervisor for arm-based secure mobile phones[END_REF]. This approach is now superseded by ARM's HYP mode. x-hyp4 is a new french little hypervisor for ARM world but only runs on QEMU by the time this paper is written. Finally one can see that all these hypervisors do not offer hardware based solutions for a secured virtualization. We finally found EmbbededXen. A work made by the "Haute Ecole d'Ingénierie et de Gestion du canton de Vaud" (Switzerland) 5 for which the source code is available and runs on a Zynq-7000 platforms [START_REF] Rossier | Embeddedxen : A revisited architecture of the xen hypervisor to support arm-based embedded virtualization[END_REF]. A further implementation has been realized on a HTC desire smartphone. This little hypervisor has great qualities for our works: all the source code (hypervisor, Dom0 and DomU) is included in only one binary file making it easy to upload to the board via NFS or put in flash memory, it is u-boot compatible (so is the Zynq), some security has been deployed on RAM management, hypercalls/syscalls not used in Xen mode and they have initiated a particular mode. The presented work is well mature enough to try to add some new features to it. This project is still in progress and the hypervisor seems easy to manage for prototyping.

Trusted Computing

The trusted computing group (TCG) was primary involved in desktop PC and huge servers but was not really organized for embbeded world and virtualization. Their specifications for virtualization [START_REF]Trusted Computing Group: Virtualized trusted platform architecture specification[END_REF] have been published in 2011 and should still been in effect. More than this, virtualization is still considered as an independant domain besides embedded systems. Facing the trend, TCG worked hard to publish a white paper: TPM MOBILE with Trusted Execution Environment for Comprehensive Mobile Device Security [START_REF]TPM%20MOBILE%20with%20Trusted% 20Execution%20Environment%20for%20Comprehensive%20[END_REF]. This solution involves greatly the TrustZone and a great part of the trust should depend on it. But one can't speak about trust computing without mentionning Trusted Platform Modules (TPM) which are the heartbeat of a trusted solution. A version called 1.2 has been widely deployed (over 100's of millions of chips) but is now out-of-age due to scientific improvements on the domain of malicious computing. The up-to-date version is the newly revision 01.07 published in may 2014 which is called "family 2.0" whose total specifications represent more than 1000 pages. The first functional TPM (v1.2) is now obsolete and 2.0 specifications aim at giving more insurance. TPM 1.2 had some limitations and the first one is its age: 2003. In terms of cryptography, only SHA1 and RSA 2048 are fully supported because the US government wanted to avoid exposed symmetric for export concerns. To protect confidentiality, RSA2048's key of 112 bits is not strong enough nowadays [START_REF]Recommandation for key management : Part 1 : General (revision 3)[END_REF]. To build a policy, this version of TPM had only 3 authorization elements (Authorization value, PCR state and locality) to be combined for a total of 8 possibilities. In terms of target, this version only aimed at desktop PC. The insurance given by the chip could be deactivated from the BIOS by a user. The owner of the TPM controlles all the security and privacy functions. TPM 2.0 version has an easier way to define security to their "owners". There are 3 separate domains: security (to protect the security of an user), privacy (to expose the identity of the platform/user) and platform (to protect the integrity of the platform services) and for each domain we find proper resources and controls. When one found only one hierarchy for the platform OS which is the user (for the storage) with the former TPM, one has now 2 more: one platform hierarchy to be used by the BIOS and one endorsement hierarchy for the TPM identification. Each hierarchy has its own resources (primary seed to generate EK, enable flag, authorization value, authorization policy). 12 authorization elements and a newborn security policy based on logical AND and OR gives fine grained access control over TPM keys or data like authorization value, locality, PCR state, time limited, duplication, and so on. Some other explanations are presented in this article [START_REF] Osborn | Trusted platform module evolution[END_REF]. Finally, PCRs can use many hash algorithms and doing so, an extension of a PCR must now include the hash and the ID of the used algortihm. Those versions are therefore and, for good, incompatible. Boot process is the unavoidable base to build a secure chain of trust. First, boot ROM acts as the hardware root of trust for verification (RTV) and forms the start of the root of a transitive chain of verification. The software in the boot ROM locates the first boot phase software in some form of non-volatile storage. The boot ROM could then performs the following sequence of operations:

1. Measures the located image and determines the validity of the measurement, 2. Checks that the version number stored within the image is valid, 3. If all checks have passed, then the device executes the loaded software.

Secure boot is then used only for the early-booted device firmware up to the point of launching the main operating system (OS) boot loader. Whenever an additional module of firmware code (or a data file in some cases) is loaded, the following steps are executed:

1. The code module is measured, 2. The validity of the measurement is determined, 3. If a storage mechanism such as a TPM is available, the measurement is extended into that storage, otherwise it is discarded.

If the Boot ROM is trustworthy, code that fails validation will not be launched during the secure boot process. At last, measured Boot is the process followed once a TPM is available during the boot process to carry on the build of the complete trusted process to its end as illustrated in figure 3.

To allow a program to have access to a TPM chip, a software interface must be provided which is called Trusted Software Stack (TSS) in the TCG terminology. 3 interesting works have been found on this topic. The first one [START_REF] Stuble | tss a simplified trusted software stack[END_REF] was about a micro-TSS and has been later quoted by the German Federal Office for Information Security (BSI) 1 . For full open-source implementation of a TSS one can follow two projects: Trousers in C language 2 existing since 2005 and jTSS written in java language 3 since 2008. All these works are of utmost interest for their deep study of the mechanisms even if designed for TPM v1.2 family. It could seem to be a very good ideas to implement all the specifications in motion with the help of a large FPGA but it's impossible in a environment where resources are limited. So one has to wonder about their adequation to embedded system. A guide has recently been produced by the US Department of Commerce [START_REF]Guidelines on hardware-rooted security in mobile devices[END_REF]. This guide can be seen as an "approval" of the TCG specifications because most of its requirements may be satisfied by the TCG. Some other rules can be viewed as an expansion. But in our case, the TPM and its virtual counterparts (vTPM) will have to make a lot adjustments to cope with restrictions on silicon area, energy, power to fullfil the platform constraints. In theory, they seems to be clones of each other and their functionalities are enumerated in figure 4.

Here, we must notice that some european projects try to implement a physical realization of Trust in embedded computing [START_REF] Ponsini | Trusted embedded computing[END_REF] but, in 2010, it was in version 1.2 and recently, in june 2013, by the Institute for Applied Information Processing and Communication (IAIK) of Graz University of Technology, Austria, where a whole TPM v2.0 platform has prototyped on a Spartan3A FPGA 1 .

Fig. 4. In concrete terms, TPM and an vTPM should look like that meaning that all the functionalities must be present but may be shared.

For the virtual TPM, a basis solution has been explain in [START_REF] Stefan | vtpm: Virtualizing the trusted platform module[END_REF]and illustrated in figure 5. This first solution was solely software. Later, other were published. One get the feeling of it and deployed an exclusively hardware-based solution with a vTPM for each VM [START_REF] Stumpf | Enhancing trusted platform modules with hardware-based virtualization techniques[END_REF]. One presented a paravirtualized TPM solution which shared TPM and vTPM in only one instance [START_REF] England | Para-virtualized tpm sharing[END_REF]. Another one implement1 http://trust2013.sba-research.org/wp-content/uploads/2013/06/Martin-Pirker.pdf a property based TPM-vTPM solution [START_REF] Sadeghi | Property based tpm virtualization[END_REF]. But none of these solutions applied to ARM processors and they were too old to get the Zynq-7000 capabilities into account and the new specifications of the TPM v2.0.

Threats

As one consider threats at the scope of an entire SoC, one will have to look at the whole scope of possible vulnerabilities and later only have a glance at those which could create a vulnerability of our study concerns. Attackers who can exploit the vunlerabilities of a SoC can be divided into 3 classes: 1 kiddies with little knowledge, engineers with solid knowledge and funds and finally states or organized crime which include terrorism. Their objectives will also be different depending on the range of the power they own (personnal challenge, technologic race or spy/cyberwarfare). For a SoC like Zynq-7000, one must care about 3 categories of vulnerabilities that exists: hardware, FPGA and software (virtualization). Network threats will be less studied because the fact that the network stack is badly coded or the network protocole not respected is not of our concerns. At the lower level, there are a lot of threats for microelectronic hardware which could also be classified in 3 categories:

1. Backdoor in hardware 2. Hardware vulnerability 3. Hardware assisted malware.

Most of these malwares can be found at production level. A malicious modification of hardware is more than possible. It can provide a very good advantage to opponents and worst in the case of security or critical domains. Here the vulnerability is at the Hardware Design Language (HDL). If the firm is fabless risks are greater. The supply chain for integrated circuits (IC) should be trusted from the designers to the end-users. Exploiting hardware vulnerabilities can lean to put a rootkit somewhere on it. For example, the Raksasha malware1 built-on with free softwares supports about 230 x86 architecture motherboards. This bootkit is possible due to 30 years old mandatory compatibility of the Intel hardware architectures 2 . Updating/upgrading an obsolete hardware is no more an accurate solution. For FPGAs, there are also sources of trouble. If not protected, a bistream could be counterfeited, cloned or stolen. The resulting effects of these threats, appart from economic and social damage, are that reliability will certainly decrease and security/safety won't be assured anymore. In critical systems like military, aerospace or medical, results can be human death. About threat on virtualized environments, one must consider that there are two sorts of possible attacks: those that are specific to general purpose computing and those that are specific to virtualization. In this article, we only focus on virtualization-specific threats. Compromizing the underlying hypervisor can be possible due to a physical vulnerability: on boot, legacy BIOS could be infected by a bad code that could corrupt the following startup sequence. Later, on the hypervisor side, the results can be a compromized hypervisor that has implemented hidden functions, installation of another malicious hypervisor (example: blue pill Virtual Machine Monitor (VMM) rootkit) and at last a deactivation of the targeted hypervisor. It would be then possible for an attacker to try to modify one of the VMs before they start. Managment interfaces can then be the target of an attacker. In case it is running under a well-known vulnerable operating systems (OS), the task should be easier. Threat can also come from network or a compromized guest that could "escape" off its cage. At upper level, a guest can be the target of attacks from Internet or from an already compromized guest. A simple goal could be to try spying the activity in an hypervisor or another VM. An infected application could do a sequence of instructions that it was not supposed to do inducing a possible leak of informations. These malicious actions conduct malware programmers to adapt their attack technics to this new playing ground: the possibility for a malware to infect all the virtualized platform forces the anti-virus suites to move their product downto the hypervisor. And again, an iterating challenge will be to identify the underlying hypervisor to exploit its vulnerabilities [START_REF] Pék | A survey of security issues in hardware virtualization[END_REF] [START_REF] Pearce | Virtualization: Issues, security threats, and solutions[END_REF].

Finally, a new task specific to virtualization is migration of VMs. This process, from the deactivation, the transfer and the resuming of a VM with all its configuration is a new problem to care about. The attacker could try to replace the guenuine VM by a malicious one. If the blob is not protected enough, he could also try to get some secrets. A threat to homogeneity of embedded systems has been pointed out due to virtualization as too strong isolation can be a flaw for cooperation between process [START_REF] Aguiar | Embedded system's virtualization : The next challenge ?[END_REF]. This means that forbidding the share of informations between guests/applications can force software designers to employ less secure solutions to get the needed information. An other approach in ordering malwares have been made in [START_REF] Murakami | A hypervisor ips based on hardware assisted virtualization technology[END_REF]. What is relevant there is that one can again see that researchs had been made on an Intel platform. Nevertheless, ARMv7 cores could possibly suffer from such malwares due to the only CPU mode left for both guests and applications: the user mode. There is a special device in ARM architectures which is called TrustZone and act partly on the hardware side and partly on the software side. The main problem with this secure device is the way it can be programmed. It is not well documented and not easy to play with. Recently vulnerability was detected and presented at the Black Hat USA 2014 conference in [START_REF] Rosenberg | Reflections on trusting trustzone[END_REF] and [START_REF] Roth | Next generation mobile rootkits[END_REF] in the Hack-InParis conference 2013. More that this, when one codes an application in the TrustZone, one must send the package to the motherboard provider to be signed and install at boot. So the keys of our own security are lawfully given to them. There is also some vulnerabilities in TPM implementations. In some TCGenabled platforms, communication channels (buses) between TPM, RAM and microprocessor could be unprotected. Moreover, microprocessors could use an external boot ROM to store the Core Root of Trust for Measurement (CRTM). This CRTM is a a piece of executable code starting the measurement of bootstrapping components. It must be an immutable portion of the platform initialization code that executes itself on resets. If the ROM could be switched to inject malicious boot code and compromise the chain of trust, TPM will be of no use at all [START_REF] Eisenbarth | Reconfigurable trusted computing in hardware[END_REF]. Recently, Rakshasa1 malware proves to inhibit the use of TPM of an Intel platform [START_REF] Brossard | Hardware ackdooring is practical[END_REF]. Even if trusted computing means confidence through the early powering of the platform to the running of user high level applications, backdoors can be now inserted at gate level and their identification be more and more difficult. And if virtualization is introduced in embedded systems, with many VM, one have to cope with an extended way to carry on guarantee of integrity to all underlying domains. That's why ,three topics have been identified to develop a solution which is aimed to bring more insurance to the virtualization for embedded systems: trusted computing that gives insurance, up-to-date hardware and virtualization which mainly gives isolation.

Contribution

What we propose in this article is to implement a solution as light as possible, to offer integrity, confidentiality and authorization to an embedded hypervisor, considering TPM and virtual TPM implemented on an Zynq-7000 platform which featuring both a general purpose processor (GPP) an FPGA on it. The objective should consist of (i) an hardware IP which will contain new developments (blocks), reuse of some of the opensource best ideas and as secure as possible against hardware attacks, (ii) hypercalls extensions for the hypervisor and (iii) a software library containing some of the main functions implemented in C and assembly language. This secure solution is intended to act at two levels. The hardware level will have to give trust of the integrity of IP to be plugged onto the programmable logic: this will be an measured boot and not only secure boot. The software level will have to complete and extend the chain of trust to the end-user application: the VMM which must trust the launch of a virtual machine and an application inside a VM has to give guarantee of its integrity to the uperlying operating system or remote system. The expected solution could look like figure 6.

Threats Models

As we state previoulsy, we work on an entire platform. The trusted computing base we are trying to define has to protect the system and must be able to protect its own security. See the definition of the trusted computing base in the Orange Book Security [4]. And we can mention that if trust is good, control is better to help reducing threats. The hardware threats will be mentionned and taken in account only to minmize what actually exists in the state of the art. In fact our studies has to find a solution only for software attacks. We should care only about voltage spikes and frequency shifts (i.e: power faults) that are important for the IP. We will have no action on the ARM Cortex-A9 in terms of making a counter-measure for a possible hole in the ARM Coretx-a9 processor. Likewise, we have no possible action on a BIOS attack resulting in the corruption of it. And finally we won't fight against a possible hardware trojan or backdoor in the Zynq-7000 development board. On an other CPU (OpenSparc) some solutions has been studied in [START_REF] Waksman | Silencing hardware backdoors[END_REF] and implemented. On the software side, we can't do anything against a badly coded application.

The hardware solution we propose to help virtualization is to give a proof of integrity that even if the code is bad, this is this bad code that will be executed as asked. The proposed solution will be implemented to give insurance that what is running or about to run will be authorized to be launched. Another insurance will be to try to give a guarantee that the running hypervisor has not been modified since the initialization of the platofrm. At the HDL level, solutions have been implemented in "Silencing Hardware Backdoors" [START_REF] Waksman | Silencing hardware backdoors[END_REF].

The Hardware Platform

The proposed IP should be built-up with several differents pieces (blocks). Some of the pieces will be a part of our contribution and some picked up from opensource world and/or academic researchs with the permission of their creators. Of course, all the beginning work will consist of a definition of each of the elements, their role, their data in and out. The main work will be the development of the TPM/vTPM IP which will be feeded by a secure boot and which will offer services to upper levels through a software stack.

The sensitive problem of the chain of trust The anchor of trust lean on an secure and measured boot. In secure boot, each part of loaded code will act as a proxy for the next element to be loaded but it stops until all the checks made success. If a check fails then the boot process stops and the platform is also stopped. The right term, in TCG terminology, is verified boot but secure boot is more widely used: this is made with comparison of signed parts of the boot process. But we have to monitor all the boot process too but in a different way: measurement. First, the component that measures the initial boot must be trusted. This CRTM is hardware-based. Then, if the loaded piece of software has been measured and proves to be reliable, the component can measure the next software to be loaded, and again there is a solid basis for trust. And this process is iterated for each step, ending with the launching of an user application inside a VM as explain in figure 7. On the Zynq-7000, however, the very first part of this process (called stage-0) Fig. 7. measured boot: measuring, launching, reporting is not accessible to the designer and/or the user! Unfortunately, the Zynq-7000 board does not offer the possiblity to modify its BIOS to make a Core Root of Trust. On this point we will have to trust Xilinx because we will have no possible action on the stage-0 boot and we have to make this hypothesis: hope that the first part of the boot chain of the Zynq-7000 (stage-0) is strong enough to give us insurance that we can plug our IP securely on the PL. These Xilinx restrictions cannot be bypassed. But later, playing with authentification/encryption, we can implement a large amount of partitions in our first stage boot loader (FSBL) or second stage boot loader (SSBL) to allow the leaning of a rather secure solution. And this solution will be the TPM/vTPM IP for a secured virtualization. This can be seen in Xilinx documentation [START_REF]Xilinx: Secure boot of zynq-7000 all programmable soc[END_REF] and [START_REF]Xilinx: Zynq-7000 all programmable soc secure boot[END_REF]. All the measurements made consecutively will be stored, for some parts in an non-volatile memory (NVM) and other parts in volatile memory registers called PCR. As a result, our solution will start on FSBL.

The I/O interface is the first element of the IP that will receive requests from the software part of the systems and send back a result as soon as possible. Two separated buses for in and out flows are a good solution to later develop parallelism. The width of such a bus will be 32 bits to keep fully compatible with the TCG current requirements. A command received by this interface would have been verified at hypervisors level and carry the id of the VM. The I/O interface will put this command in a scheduler considering its priority (given by the hypervisor) and policy (given by the TPM). One command will be executed at one time and then, this command will "own" all the TPM. This is shown in figure 8. Before launching the execution of the command, the I/O interface will have to verify that the previous command has ended its work and that the required algorithms are available. If not the case, partial reconfiguration will load the correct bitstream after having verified its integrity at last. Some different operations will successively follow the following algorithm 1 The internal bus of the TPM/vTPM will be shorter than the original one due to the center position of the execution The width of these buses only need to match the width of a TPM2 command, so 32 bits. In fact, this layout Algorithm 1 Managment of a TPM2 command issued from the VMM ou VM but transmitted by DomT Require: On reception of a valid TPM2 command if (command header is correct) AND (handles exist) AND (authorizations are valid) then make it execute wait for aknowledge create the return header else send error with error id report error end if has been chosen considering that having shorter buses is better a long one in terms of side channel analysis aand and to avoid latencies.

The execution engine. One wonder in the case of programmable logic if it would not be more interesting to think about an alternative layout for our TPM-vTPM in a form of a star network. This will move the bulk of work to this unit knowing that only one command coming from VMM or a VM owns the TPM at one time (only one state is possible). The figure 9 also shows the I/O interface will now only interact with one element and not all the possible element in a TPM. The symmetric and asymmetric crypto engines. There are 2 sorts of engines and TCG specifications explain that more than one engine can be deployed in TPM. As place on the Zynq-7000 is not extensible, we have to consider partial reconfiguration. Bitstreams of each algorithms will have to be shipped with the FSBL and installed in non-volatile memory to be called as necessary. At this point, we must notice that Zynq-7000 has already a RSA2048 algorithm for authentication and an AES256/HMAC algorithm but only for decryption. The algorithms we plan to use already exist and will be adapted to our developments. Ellyptic curve cryptography (ECC), of course is mandatory. Some of the other cores could be found on opencores website1 for example. In our bitstreams, care will have be taken to reduce vulnerabilities of our designs to avoid information leakage [START_REF] Kastner | Threats and challenges in reconfigurable hardware security[END_REF]. For this, flexibilty of SRAM FPGAs has proved to be of a great advantages [START_REF] Bossuet | Dynamically configurable security for sram fpga bitstreams[END_REF] to quickly upgrade, many times, a modified version of an IP.

The PCR. The first 8 PCRs (number 0 to 7) will be used by all virtual PCRs (vPCR) because they represent the platform secure state, so only one bank of these PCR will be created in an read-only mode for the VM. The 16 others will represent the VM personnal measures. See figure 10 for explanations. Hash algorithm ID will have to be added to the measurement on each PCR to reflect the property that a PCR can choose from more than one hash algorithm. TPM PCR values will also have to be available both locally and remotely for attestation. For example, a TPM will be able to digitally sign the PCR value to help remote attestation and avoid tampering, corruption, and malicious software.

The key management for a TPM, depicted in figure 11, is not a public key infrastrucure (PKI) as one can have in large systems. In fact, it will have to be as reduced as possible considering that we are in an embedded system. The Endorsement key (EK) will be kept and the Storage Root Key (SRK) protected in NVM because they are the basis of all future credential extensions. The Attestation Identity Key (AIK) derived from EK will be stored on a volatile memory, inside our TPM (but encrypted). AIK will be used to sign data and an EK Credential. It is in fact a X.509 v3 certificate designed to issue credentials for other restricted signing keys (Attestation Keys) [START_REF]Credential profile ek v2.0 r12 publicreview[END_REF]. So, this credential will be used to quote (validate) AIK of VM. All the keys (except for the TPM) will be created in our TPM and will be independant from each other for migration purpose.

the Random Number Generation (RNG) has two use cases in a TPM: internally, generate keys and externally generate key using software or feed an pseudo-RNG. That's why, one of the uses of a TPM is to feed /dev/random on a linux box. These utilizations will be preserved and extended to the use by vTPM.

The hypervisor

We will work on a fork of EmbeddedXen. We know that specifications from the TCG are to be followed in differents domains of this consortium if we look for a minimum of compatibility. But, too much specifications deployed on a small part of silicium would result in non-sense developments. Our work will be to get the specifications we think to be of a prime importance for security knowing that all of them will not be implemented on a SoC (for example: whole policies specifications on a small embbeded system whose configurations are often static). We will try to respect as far as possible recommandations from XenProject to implement security on the Zynq-7000 board. For example: all extra-services (even security) should not not be implemented in Dom0 but must have a little VM dedicated to them. This is done to not enlarge the Trusted Computing Base (TCB) which is the area of code exposed to attackers. We also have to develop some hypercalls to catch all the requests to the TPM/vTPM send by the VM but also by the VMM in the case of launching a VM and realize an integrity check before. This little VM will only manage the demand/response to/from the TPM. It will provide some little services like checking the validity of a command, avoiding deny of service (DOS) attack to the TPM by counting the number of sendings from a VM, software attestation of the source (signing with a dedicated private key in the VM and attesting with its public counterpart in the I/O interface of the TPM), adding an predefined ID of the callling VM to the send command for further identification and management of the request/answers, for a short list. All the TPM2 commands will not be implemented (due to lack of time and may Fig. 11. Key managment as explained in [START_REF] Stefan | vtpm: Virtualizing the trusted platform module[END_REF] be place on the silicon area). Basic operations will first be done followed later by more evoluted ones. Here, we must notice that all TPM2 commands have a description in C language which helps for rapid implementation. The TSS offered to the VM will not be as detailled as it should be for a complete implementation. Two distinct parts will be implemented in our DomT: One in kernel mode called trusted device driver (TDD) et one in user-mode called trusted core services (TCS). TDD which run in kernel mode will be implemented as the only link between the TPM and the rest of the platform (including the VM managment Dom0). In the VM, the trusted service provider (TSP) will be the only access point for a TPM/vTPM request. One can again see that the DomT is at the crossroads between software and hardware in the figure 6 of this article.

Conclusion and future works

There is two parts in our works. One leans on hardware and have to code into VHDL plus firmware in C/assembly language. One leans on software and offer services upon an already existing but modified hypervisor. We think this solution is an interesting one by the way the hypervisor can be modified wihout side effects to the trust offered at different levels. The IP can also be modified and the hypervisor will not be impacted by theses evolutions. The supporting Zynq-7000 board has extended capacities (ASIC/FPGA) that allows this solution should ideally be a "plugin". One great challenge is to make a complete system where latencies will not be a major drawback. One other point to care about is the size of the IP. There may be some trade-offs in implementations to make there. The TPM-vTPM IP is the most heavy work to realize, the basis of all future work that could be further imagined. The first bloc to be initiated is the I/O interface, then will follow the internal bus, the execution engine, the PCR/vPCR, the crypto-engines and so on. At upper software level, little changes are to be made to the chosen hypervisor. At first a software stack to allow developpers to use hardware IP services for each VM. And second, the implementation of a small VM dedicated to the managment of all the transactions with the TPM/vTPM. The last part of the work belongs to the software engineer in the use the avaliable calls to the TPM.

Fig. 2 .

 2 Fig.2. The complete secure flow for the Xilinx's Zynq-7000 board.[START_REF]Xilinx: Secure boot of zynq-7000 all programmable soc[END_REF]

Fig. 3 .

 3 Fig. 3. State-of-Art of a complete secure boot chain.

Fig. 5 .

 5 Fig.5. The mostly implemented solution in para-virtualized hypervisors[START_REF] Stefan | vtpm: Virtualizing the trusted platform module[END_REF].

Fig. 6 .

 6 Fig. 6. Overview of the proposed solution. A leightweight hypervisor of Xen type with some VM looking for trust in an FPGA implemented TPM

Fig. 8 .

 8 Fig. 8. An important key to TPM functionnality

Fig. 9 .

 9 Fig.[START_REF] Murakami | A hypervisor ips based on hardware assisted virtualization technology[END_REF]. In such a configuration, we clearly see that the execution engine is at the crossroads between TPM and vTPM

Fig. 10 .

 10 Fig. 10. a VMM will include one READ-ONLY link to the original 0 to 8 PCR bank and a dedicated 9-23 PCR bank

http://www.sierraware.com/arm hypervisor.html

http://www.fentiss.com/en/products/xtratum.html

http://wiki.xenproject.org/wiki/XenARM

http://x-hyp.org

http://www.heig-vd.ch/rad/reds

https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/Studies/TSS Apps/TSS-Apps en.pdf? blob=publicationFile

2 http://trousers.sourceforge.

net 3 http://trustedjava.sourceforge.net

http://watchguardsecuritycenter.com/2013/05/30/hacker-profiles/

http://2012.hackitoergosum.org/blog/wp-content/uploads/2012/04/HES-2012jbrossard fdemetrescu-Hardware-Backdooring-is-pratical.pdf

2 http://resources.infosecinstitute.com/hardware-attacks-backdoors-and-electroniccomponent-qualification/

http://fr.slideshare.net/endrazine/defcon-hardware-backdooring-is-practical

www.opencores.org